TST: pandas/util/testing : test improvements and cleanups
A few things
1. Make with-statement-capable `assertRaises` and `assertRaisesRegexp` (which I want to use later in a cleanup of some of the parser tests).
2. Earlier introduction of `assert_attr_equal` changed it so that, if one object had an attribute that was `None` and the other did not have that attribute at all, it would pass. This is now fixed.
3. combines `assert_panel_equal` and `assert_panel4d_equal`, because they are both doing the same thing. Now it's just `assert_panelnd_equal` with specific assert functions for each.
4. Switched unnecessary `check_index_freq` check in `pandas.io.tests.test_pytables:TestHDFStore.test_index_types` to be `check_series_type`, (because none of the tests ever produce objects with `freqstr`)
5. Removed `check_index_freq` argument and corresponding code from `assert_series_equal` since it's not being actively used anywhere in the test suite

the freq checks are really to avoid having a separate method to check index vs index and datetime index vs datetime index, as the only the latter has a freq
 @jreback Actually, none of the tests pass if you force the frequency check to be explicit. None of the objects produced have a `freqstr` attribute in that test.
 right - even a datetime index does not necessarily have a freqstr 
 @jreback to be really clear, all I mean is that making it so that both objects have to have a freqstr is fine for the entirety of the test suite, it's just that one test that was doing it wrong (probably because check_freq was added and it didn't update its positional arguments).
 @jreback at least in 2.7, it looks like that test is the only place in the entire test suite that checks index frequency.
 it doesn't need to be explicitly test I think
because equals on 2 datetime indexes checks it
 @jreback yeah, I'm just running this build right now - https://travis-ci.org/jtratner/pandas/builds/9791919 - which puts an assert False under the check_freq part of assert_series_equal and also checks that none of the functions in that one test case have freqstr. If it doesn't, are you okay with removing that argument and branch from assert_series_equal?
 @jreback if you're okay with this, I'll squash it together - just wanted to leave them separate for now in case you didn't want a part of the PR.
 this is all ok

that test was probably just thrown together (obviously should have kw args)

go ahead and I'll merge
 @jreback does this need to go in docs? if so, since this is small, which file?
 @jtratner what do you mean go in docs?
 meant to say release notes. I thought you all had said something about
wanted to move small fixes out of one doc (release.rst? v0.13.0.rst?)
 oh....what I meant was that if you say fixing bug xyz, just put the reference in the release.rst. If its a feature (or important bug fix) or you just think most users should know about it in whatsnew then go ahead and put it in there TOO. But for the most part, no point in duplicating in BOTH release.rst and whatsnew (e.g. v0.13.0).
 merge?
 yes.
 thansk!
