Index can be created with multiple NaNs

[flexatone]

This was first identified in #242. An isolated example is below.

>>> sf.Index((1, np.nan)).union(np.array((np.nan,)))
<Index>
1.0
nan
nan

[flexatone]

This is in part due to an issue in AutoMap:

brandtbucher/automap#5

[flexatone]

This is also due to an issue in how NumPy chooses not to handle NaNs in some operations;

>>> np.union1d(np.array((1, np.nan)), np.array((np.nan,)))
array([ 1., nan, nan])
>>> np.unique((np.array((1, np.nan, np.nan))))
array([ 1., nan, nan])

This appears to be a 10-year old issue:
numpy/numpy#2111

[flexatone]

As this is an issue common to dict as well as AutoMap, as it stands presently this is expected, though confusing behavior for a mapping object. I think the only option, from SF's perspective, is to consider disallowing NaNs in Index, though that option will cost performance.

>>> dict.fromkeys(np.array((np.nan, np.nan)))
{nan: None, nan: None}