BUG: Take method of NumpyExtensionArray now returns another extension array with the correct dtype.

[aijams]

In the edge case when called with integer arrays and asked to access non-existent entries (to be replaced with NaN), the take method of NumpyExtensionArray produces arrays whose dtypes don't match their underlying data.
Specifically, take promotes the underlying data to a floating-point type, but doesn't promote the dtype of the extension array to match.
These changes ensure that the result of this method has the correct dtype for its data.

• closes #62448
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

[aijams]

Several tests are currently failing due to a new version of numexpr.
#62545
All other tests pass.
I hard-coded a list of dtypes in take to check for the integer types that can't store NaN values since setting the dtype on an extension array after it's created isn't allowed. I have yet to think of another way to correct this issue without modifying the base extension array class to allow its dtype to be modified.
Let me know if you thought of a better way of approaching this.

[jbrockmendel]

this test is unnecessary

[aijams]

I added this test to make sure that take does the expected thing when not allowed to fill missing values. I did a quick search, but I didn't find any other tests for this. There are other tests that work with this method, but I would like to have a test explicitly for this behavior to check for regressions and make it clear that take should preserve dtype if it can. If you still think this test isn't needed, can you explain why you think so?

[jbrockmendel]

this is tested in the extension tests

[jbrockmendel]

@aijams if you address this we can get this merged