add a way to sidestep common invalid but interpretable units in CCDData

[eteq]

This PR addresses an annoyance I've encountered several times now. It's nominally a dupe #7608 but it's also related to #7619.

Arguably, this PR is actually counter to some of the discussion in #7619 but I'm raising it because it's not clear #7619 got resolved, and I keep running into this particular case. So my concrete proposal in this PR is to have a very explicit set of "known bad but unambiguous" units that CCDData knows how to translate. I'm not proposing we promise that this list is complete or anything like that, but instead to think of it more like the from_name machinery in SkyCoord, which is very convenient even if it isn't always 100% reliable.

So basically this PR sets up machinery to do this, and populates with the specific case of #7608 with the expectation that we can add more in the future as users encounter them. I'd say they have to justify them, which I'm doing here via #7608.

cc @mwcraig @MSeifert04

[mwcraig]

Given https://github.com/astropy/astropy/pull/9397/files#diff-927444a7463d962e28a3e4db8f89dcedR613 this approach seems completely fine -- basically, we already do special casing for one unit ADU → adu so adding more makes sense to me. If we don't handle the common cases smoothly then users aren't going to use it.

While it is the case, as discussed in #7619, that one could take this too far there simply aren't that many variants (leaving aside spectra) that I can think of.

(I don't think this requires additional documentation, just to be explicit about that point).

I've restarted the job that had failed during apt install....assuming this passes it is ready to go.

[bsipocz]

restarted the cancelled tests, and added the label based on the review above.

[bsipocz]

Thank you @eteq!