Categorical.(get|from)_dummies
Simply converting categorical variables to and from dummy variables.

- [x] closes #8745
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

Intentionally smaller-scoped than #31795 (and indeed `get_dummies`) as a broadly useful MVP which can be chained with other basic functionality. The tests are fairly rudimentary and I welcome any edge cases which should be picked out.

## For discussion

### from_dummies

* class method rather than free function: Keeps categorical-related functionality together, reduces surface in the global namespace, more obvious what is produced.
* silently drop column with NA header: wasn't sure about this. Maybe it should raise a warning?
* No handling of masked dataframes or dataframes with NA values
* No subsetting or renaming of columns: callers can do this themselves

### to_dummies

* Name: I went for `Categorical.to_dummies` instead of matching the free function `get_dummies`. The symmetry of to/from aids understanding, and using `get_` might imply A) that something is being got, which it isn't or B) signature/ feature parity with the existing method, which wasn't a design goal for me.
* `to_dummies` return type: `cls.to_dummies` returns bools, where `get_dummies` returns uint8s by default, which doesn't make a lot of sense to me as we are representing boolean data (and they're the same in memory anyway). Dummy variables are generally used for regression where a continuous variable is required, so ints don't get us any closer to what we may want, and being able to index into the categories using the row may be valuable.
* No `dtype` argument: I didn't see any benefit of `cls.to_dummies(dtype=float)` over `cls.to_dummies().astype(float)`. The latter is more explicit, no slower, and minimises API surface.
* No `prefix`, `prefix_sep` arguments: these unnecessarily assume string column headers. If someone wants to rename their columns, they can: IMO it's not a core requirement of this method.
* `dumma_na` replaced with `na_column`: if we're including the argument, we may as well let the user decide what they want to call their column, using the dtype they prefer (e.g. `"other"`, `-1` etc). They can always supply `np.nan` if they want `get_dummies`-like behaviour.
* No `sparse` argument: This I regret. Producing a sparse array would be valuable. However, it would drastically complicate the method, so I left it out for the MVP. The caller can always sparsify it after it's produced, so long as RAM isn't an issue for the temporary df.
* No `drop_first` argument: If someone wants to drop one of their columns, they can (`cls.to_dummies().drop(columns="my_col")`): again, not a core requirement of this method. Broadly speaking, I'm not in favour of adding arguments to save the caller <=1 line of their own code unless there are e.g. speed gains.