bugfix: make the data translator registry prefer exact cls matches over isinstance matches

[bmorris3]

Description

This PR supports more precise control over data translators in the registry. In a STScI use case, we have added a translator for a specific subclass (lightkurve.LightCurve) of a base class that already is in the registry (astropy.table.Table via glue-astronomy). We noticed that a glue translator for the base class (Table) is getting returned as the matching handler via data_translator.get_handler_for, even though we have an exact class match for the subclass (LightCurve) in the registry.

This PR gives preference to exact class matches in the translator registry. It now checks for exact matches via data_or_class is expected_cls between data class and the expected class in the translator registry, before following up with the original isinstance call if no exact match is found.

[astrofrog]

Coming back to this I don't fully understand why the suggested change would work any better since instead of checking isinstance we now check for exact match then for isinstance, but we do both these checks for the current type in the loop. So let's say the order of the iteration is to check Table then Lightcurve, and the user passed a lightcurve object, then the code would do:

• Check Table exact match -> no
• Check Table subclass -> yes
• Break

And it would never get to checking lightcurve.

So I guess there are two questions:

• Why not just use priorities to make Lightcurve be a higher priority than Table?
• Is it that here what we really want to do is prioritize exact matches if the priorities match? (in which case the code will need to be adjusted to do this)