PERF: reducing dtype checking overhead in groupby
This is not to be merged as is, but rather to illustrate how the generic dtype checking methods we have cause some overhead in certain operations (or at least in the benchmark cases we have), and how this is also relatively easy to solve.

Using the `GroupManyLabels.time_sum` case (a wide dataframe):

```python
ncols = 1000
N = 1000
data = np.random.randn(N, ncols)
labels = np.random.randint(0, 100, size=N)
df = pd.DataFrame(data)
df_am = df._as_manager('array').copy()

In [3]: %timeit df_am.groupby(labels).sum()
38.2 ms ± 861 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- master
26.6 ms ± 486 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- PR
```

So a combination of 1) more specialized dtype checks and 2) caching some repeated dtype+op-dependent helpers quickly gives a decent speedup (and there is some more room for improvement with similar changes). 

So at some point I think we should look a bit more into our `is_..` checks and have eg specialized versions that eg assume you already have a dtype (I know we discussed this before, not directly finding a relevant issue), and use those throughout the codebase where we know we have a dtype object (might be a good issue for someone starting to dive into the code base).
yeah looks nice, i agree should try to refactor is_* to make them more strict is a good idea The dtype.kind checks i definitely like.  How big a difference does the caching make? prob could work if you can rebase @jorisvandenbossche  This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. this would be nice to do > this would be nice to do

closing as stale. but feel free to reopen when ready.