loaders: lcviz support

[kecnry]

Description

This pull request implements additional flexibility into the loaders framework that is necessary for downstream use by lcviz via https://github.com/spacetelescope/lcviz/pull/187, including:

• failing gracefully if standardizing metadata fails
• enable lcviz (alongside "deconfigged", "specviz", and "specviz2d") to use loaders by default
• allow lcviz to use fits parser (needed for DVT importer)
• allow importers to provide list of viewer classes to ignore when attempting to load data - allowing them to give a different viewer (to potentially create) as priority over other viewers that might support loading the data. For lcviz, TPF data can be loaded into the light curve viewer, but should not be by default, and instead we want the importer to automatically create an image/cube viewer if it does not already exist.
• move SelectExtensionComponent to template mixin (and rename to SelectFileExtensionComponent) so that it can be shared with other importers (used to be isolated to spectrum2d)
• generalize SelectFileExtensionComponent to be able to use filters and to track the indices in the hdulist of each item
• multiselect support for SelectFileExtensionComponent
• viz.show() now defaults to showing the loaders panel if there are no data loaded (rather than the previous implementation of no viewers)
• generalize app.return_unique_label to allow passing a list of strings (useful for plugin component selections that might be used by downstream loaders, etc).

Change log entry

• [x] Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts, list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• [x] Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• [ ] Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• [ ] Do the proposed changes follow the STScI Style Guides?
• [ ] Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• [ ] Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• [ ] Did the CI pass? If not, are the failures related?
• [x] Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• [ ] After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?