Convert use of assert_/assert to specialized asserts in tests
An example of an exception that uses `assert_`:

```
============================================================================
FAILURE: test_class_ops (pandas.tseries.tests.test_timeseries.TestTimestamp)
----------------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 384, in _executeTestPart
    function()
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\33\pandas\tseries\tests\test_timeseries.py", line 2513, in test_class_ops
    compare(Timestamp.now('UTC'),datetime.now(pytz.timezone('UTC')))
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\33\pandas\tseries\tests\test_timeseries.py", line 2510, in compare
    self.assert_(int(Timestamp(x).value/1e9) == int(Timestamp(y).value/1e9))
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 1140, in deprecated_func
    return original_func(*args, **kwargs)
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 520, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true
```

note the line:

```
self.assert_(int(Timestamp(x).value/1e9) == int(Timestamp(y).value/1e9))
```

if this had been `assertEqual`, we'd have seen what the value were
and been able to debug easier (now fixed). (though, It should be obvious why that test is unreliable).

There are lots of these across the tests.
If someone steps up to do this, do a little bit at a time.
a PR that touches 200 tests will defy review and be stuck forever
in PR limbo.
