CLN: Optional[Hashable] in dict type hints

[topper-123]

Minor clean-up.

>>> from typing import Hashable
>>> isinstance(None, Hashable)
True

In old versions of mypy, mypy had a bug and didn't see this, but is has been fixed now.

There are many instances of Optional[Hashable] instead of just Hashable in the code base, other than in these dicts. I've assumed those should be left as-is for readability and not because it's strictly needed.

[jbrockmendel]

for a while we had an alias Label=Optional[Hashable], but i think weve been replacing that with just Hashable. if im right, then you can just go town on all occurrences. cc @simonjayhawkins ?

[simonjayhawkins]

for a while we had an alias Label=Optional[Hashable]

that was removed in #39107, although looking back, I didn't do the follow-up

And so I also missed the cases of Optional[Hashable] in the codebase that maybe should have been Label previously, but there was some discussion on when to use Label #32371 (comment) and it looks like these cases fell through the cracks.

Thanks @topper-123 generally lgtm. I don't think necessary to change the comments but nbd

[simonjayhawkins]

if im right, then you can just go town on all occurrences. cc @simonjayhawkins ?

maybe in some cases helps readablity, we have no_implicit_optional = True in setup.cfg for that reason.

[topper-123]

There are many case for function/method parameters like this:

def func_name(kw: Optional[Hashable] = None, kw_2) -> ...:
    ...

In such cases the Optional is not necessary wrt. mypy, because None is hashable. But I think it has been done this way for readability as Optional[Hashable] emphasizes that None is different than other hashables. In the dict cases in this PR, that isn't the case and in these cases None isn't special.

I don't have a very strong opinions, but somewhat prefer Optional[Hashable] in cases where None has a different meaning than other hashables to visually show the special status of None.

[WillAyd]

Thanks @topper-123