MAINT: Remove assertRaises from testing
Title is self-explanatory.  Pretty hefty PR this one.

Partially addresses #15990.

# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=h1) Report
> Merging [#16089](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/2f9c854c30385c29a905c0a9bf0b5009e99347e0?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `100%`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/16089/graphs/tree.svg?width=650&height=150&src=pr&token=eZ4WkYLtcO)](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master   #16089   +/-   ##
=======================================
  Coverage   90.84%   90.84%           
=======================================
  Files         159      159           
  Lines       50771    50771           
=======================================
  Hits        46125    46125           
  Misses       4646     4646
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `88.62% <100%> (ø)` | :arrow_up: |
| #single | `40.36% <100%> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/util/testing.py](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=tree#diff-cGFuZGFzL3V0aWwvdGVzdGluZy5weQ==) | `79.51% <100%> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=footer). Last update [2f9c854...51ed9f5](https://codecov.io/gh/pandas-dev/pandas/pull/16089?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 thanks!

awesome job! FYI (for future PR's), `tm.assertRaisesRegexp` should not be used.  Rather, we should use this paradigm:
~~~python
with pytest.raises(cls) as exc_info:
   ...
exc_info.matches(regexp)
~~~
I stumbled upon this while doing this massive PR.  Removing `assertRaisesRegexp` is going to take A LOT more work to replace than it was to replace `assertRaises`. hmm, that's going to be a change, though ok with it if its documented :>

can you create a context manager which emulated ``assertRaisesRegexp`` (or gives a better name)? > hmm, that's going to be a change, though ok with it if its documented :>

Yes, I added that in this PR.

> can you create a context manager which emulated assertRaisesRegexp (or gives a better name)?

I think the name is alright, and we do have a context manager for this (it's a port of Python 2.7's implementation). @gfyoung what is wrong with `tm.assertRaisesRegexp` ? (why should it not be used) It isn't idiomatic under the pytest framework.  Also, it is a port of Python's unittest `tm.assertRaisesRegexp` (extra bloat to test framework). Why isn't it idiomatic? I think it is *very* similar to `pytest.raises` in usage, but with a more specific functionality (just a different style in the naming)

And it is not because it is a port of a unittest function, that it is bad? i agree with joris
let's just rename to non camel The <a href="https://docs.pytest.org/en/latest/assert.html">docs</a> explicitly address `regex` matching in the form that I described <a href="https://github.com/pandas-dev/pandas/pull/16089#issuecomment-296316048">above</a>.  Also, is it not preferable to use the built-in methods instead of maintaining our own version of a port?  Does that change anything?

Also, I don't know what you think about this, but what about `pytest.warns` instead of `tm.assert_produces_warning` (see <a href="https://docs.pytest.org/en/latest/recwarn.html#warns">here</a>)?

I'm not pushing these very hard (I ask because they are the `pytest` conventions instead of `unittest` for example).  However, even if we don't make these changes, we could at least document in #15990 why they were not made. I still think a helper function is more easy to use than what the pytest docs propose to do (but nice docs actually!), but based on what they do, we can probably simplify the current implementation of `assertRaisesRegex` a lot? The current implementation of `assertRaisesRegexp` is relatively stripped down I thought.  Most of the heavy lifting is done by the context manager.  What did you think we could simplify? What I meant was that wrapping the code snippet you gave above in a new contextmanager, may be less code than the current implementation (thus, using the pytest functionality for asserting the raised error, checking the error message). 
But I didn't look in detail whether this would be worth it (actually improve code simplicity), and it may also not cover directly all cases that the current code can handle.

 Hmmm...I'm not sure how worthwhile that may be since you have to consider both cases when it is used as a context manager (`with`) statement or a pure function call (context manager used internally).  And I don't think wrapping the `pytest` snippet is flexible enough to avoid duplicating logic across both cases.