Simplify the testing infrastructure for checking warnings

[bcipolli]

In implementing #329, I've hit the need to check warnings. I believe nibabel has two different codepaths for manipulating warnings:

• nibabel.checkwarns - has classes ErrorWarnings and IgnoreWarnings
• nibabel.testing - has classes suppress_warnings and catch_warn_reset

I'd like to combine these into a single place, with a single methodology. I believe creating a CheckWarnings class, that mirrors catch_warn_reset, and eliminating the warning classes from nibabel.testing, may be the best?

@matthew-brett any advice? I'd like to resolve this one before completing #329 , if that's cool. I have time to do it today.

[matthew-brett]

Sorry - I was on a plane flying across the Atlantic yesterday...

Yes, it certainly seems like a good idea to clean these up.

I did an extensive refactor of these things for numpy - here : numpy/numpy#5682 - maybe best to use a copy of that? It had a heavy review.

We should be a little careful not to break anyone else's code with the API change.

[bcipolli]

👍 thx

[bcipolli]

OK, so given this, I am thinking to:

• Deprecate ErrorWarnings, IgnoreWarnings, and catch_warn_reset; also deprecate nibabel.checkwarns.
• New interface will be suppress_warnings (essentially IgnoreWarnings), clear_and_catch_warnings (copy from numpy), and error_warnings (essentially ErrorWarnings).

Any comments on this plan are welcome.

[matthew-brett]

Sounds like a good plan. suppress_warnings and error_warnings could inherit from clear_and_catch_warnings too, to allow for modules where the warning has already been raised.

[bcipolli]

This was fixed in #345