POC: 3-step generalized data parsing

[kecnry]

Description

This pull request is a proof of concept of a flexible data parsing framework consisting of three steps/registries: resolving (string -> file path), parsing (file path -> python object), loading (python object -> ready to inject into glue). The diff currently includes #3399.

The goal here is to build a framework that is:

• general enough to be used as jdaviz is deconfigged
• results in a single, consistent, deconfigged load_data call for users that handles most common cases by default, but accepts advanced options
• users/contributors/downstream can easily add custom support
• maintainable and debuggable
• bonus: not too overengineered or confusing 🤞

Open questions:

• would it be more convenient for users to provide a viewer that they want their data to be able to open in and then backtrack to combination of parsers required to get there?

Change log entry

• 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.

• 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?
• 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)?