"test_py3kwarn" fails when running the whole test suite

This is a known behaviour, because of extension modules loaded by previous tests (which cannot be "reloaded").

However, the warnings module store all the warnings when they appear in a dictionary attribute attached to the module which does the "import".

We may read this dictionary attribute for the purpose of this test.

Here comes the patch:
 - use test_support.__warningregistry__ to check past warnings
 - filter the warnings with "(module|package)", to be sure that they are silenced by "test_support.import_module"
 - fix test_reduce_move (it failed when run after test_unittest)


Note:
 - it requires that all "deprecated" imports are filtered through the "test_support.import_module" function (issue #7092)

Fixed with r78815.
Issue #7092 should silence py3k warnings (soon).
Next step is to activate "-3" on some buildbot.

This still seems to be an issue for OS X.  With the current trunk (r79716), I get:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -3 ./Lib/test/regrtest.py test_macostools test_py3kwarn
test_macostools
/Users/dickinsm/python/svn/trunk/Lib/importlib/__init__.py:37: DeprecationWarning: In 3.x, the MacOS module is removed.
  __import__(name)
/Users/dickinsm/python/svn/trunk/Lib/test/test_macostools.py:10: DeprecationWarning: In 3.x, the Carbon package is removed.
  import Carbon.File
/Users/dickinsm/python/svn/trunk/Lib/test/test_macostools.py:11: DeprecationWarning: In 3.x, the macostools module is removed.
  import macostools
test_py3kwarn
test test_py3kwarn failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for MacOS

1 test OK.
1 test failed:
    test_py3kwarn
[40996 refs]

I very much appreciate flox's efforts here, but IMO we really need some more robust solution to the problem of (testing + global warning state).

See also issue 4180.

Fixed with r82149.