CLN: unify NumpyBlock, ObjectBlock, and NumericBlock
This PR unifies `NumpyBlock`, `ObjectBlock`, and `NumericBlock` into `NumpyBlock`.

xref #52413

This is part of my effort to make it easier for pandas to support new-style dtypes like the variable width string dtype I'm working on that will hopefully replace usages of object string arrays in pandas (#47884). New-style dtypes have `dtype.kind` set to a null character, so using `dtype.kind` to discriminate between numpy dtypes as `pandas.core.internals.blocks.get_block_type` currently does makes it more difficult to support new-style dtypes, as I'd need to add additional checks there that will hurt performance in a hot code path. @jbrockmendel suggested this approach instead.

It wasn't clear to me what the backward compatibility guarantees are for `pandas.core.internals`. I think adding an `ObjectBlock` and `NumericBlock` that are (deprecated?) aliases to `NumpyBlock` will be sufficient to maintain back compat if that's desired.

As a bonus, it's no longer necessary to check `dtype.kind` twice in the block creation fast path - I moved the second check into the new `NumpyBlock.is_numeric` cached property - so I think this may be a tiny bit faster for benchmarks sensitive to block creation overhead.
> It wasn't clear to me what the backward compatibility guarantees are for pandas.core.internals. I think adding an ObjectBlock and NumericBlock that are (deprecated?) aliases to NumpyBlock will be sufficient to maintain back compat if that's desired.

Its complicated.  We've landed on calling pandas.core.internals.api "pseudo-public" and acknowledging that some packages (pyarrow) access them even though they're not _really_ public.  Last time we removed a Block subclass there were complaints and we ended up reverting it and changing the removal to a deprecation (which was enforced in 2.0, so now it is gone). OK, I’ll go ahead and add deprecated aliases. Thanks for the context and the prior art pointer. Will hopefully be pushing an update today that fixes the tests and addresses the comments. Is there anything I can do on my end to move this forward? Rebased to fix a conflict. Would appreciate another round of review. The test failure is unrelated. LGTM @ngoldbaum can you merge main one more time to be on the safe side Nice work @ngoldbaum 