PERF: improve IntegerArray fast constructor
Trying to improve the IntegerArray constructor from its constituents.

Example test case:

```
a = pd.array([1, 2, 3], dtype="Int64")
values = a._data
mask = a._mask 
pd.arrays.IntegerArray(values, mask)
```

```
In [5]: %timeit pd.arrays.IntegerArray(values, mask)  
2.9 µs ± 45.4 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # master
775 ns ± 41.9 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) # PR
```

So what is in the PR is *one possible* solution, to show the impact of using "general dtype checking functions" (that eg also need to deal with EA dtypes, getting the dtype of values being passed, etc). It is clear that here we can do a much more specialized check, and that this gives a considerable performance boost (in eg block/column-wise operations on IntegerArray, this is reconstructed many times). Some options:

- do an inline specialized check as done here
- define separate helper functions for those specialized checks (eg restricting to numpy dtypes)
- improve performance of `is_bool_dtype` / `is_integer_dtype` for those cases (maybe putting a check like this as a "fastpath" at the beginning of those functions might avoid more costly checks done in those functions for this specific case (eg "is_bool_np_dtype")
- simply don't do any validation at all in the IntegerArray constructor, and assume this is the responsibility of the caller
- provide a keyword in the IntegerArray constructor to turn off validation
- add a private constructor (similar as the `_simple_new` we have for others) that uses this fastpath

For optimal performance, having a way to don't do any validation at all (so also don't check the passed values are ndarray, or their dtypes) would actually even be better than what this PR does. But I also like the clean constructor we have now (eg no separate private constructor)