PERF: optimize is_numeric_v_string_like
In some of the arithmetic benchmarks (xref https://github.com/pandas-dev/pandas/issues/39146#issuecomment-799482699), just this `is_numeric_v_string_like` check takes up 15-35% of the overall time. 

This improves the performance of this check by using some ndarray-specialized dtype checks (checking the kind instead of the generic functions):

```
In [1]: from pandas.core.dtypes.common import is_numeric_v_string_like

In [2]: arr = np.array([1, 2, 3])

In [3]: %timeit is_numeric_v_string_like(arr, 2.0)
2.3 µs ± 46.9 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- master
482 ns ± 41.8 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)  # <-- PR
```
nice!  two questions, neither blockers for this PR

1) IIUC this check exists to prevent a numpy-issued deprecation/future warning.  Do we know when that ceases to be an issue?

2)  Looks like is_string_like_dtype is only used in one other place (in dtypes.missing).  lets just rip it out > Looks like is_string_like_dtype is only used in one other place (in dtypes.missing). lets just rip it out

Or I could update the helper function to what I used here, and then keep using it in those 3 places?
 > Or I could update the helper function to what I used here, and then keep using it in those 3 places?

either way i guess.  i prefer to inline the check since i frequently find myself having to go look up what the is_foo_dtype's exact behavior is OK, I am certainly fine with inlining here > IIUC this check exists to prevent a numpy-issued deprecation/future warning. Do we know when that ceases to be an issue?

Not directly an idea, but at least with the latest numpy release, you still get this wrong behaviour:

```
In [1]: np.array([1, 2]) == "a"
<ipython-input-1-c406769a5f40>:1: FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
  np.array([1, 2]) == "a"
Out[1]: False

In [2]: np.__version__
Out[2]: '1.20.1'
```

so even if that would change in a next release, we are still going to need to workaround it for quite a while ..


