Swap deconfigged_helper for config plugin tests

[jbchampagne]

This PR attempts to switch over the old config-specific tests (e.g. imviz_helper, specviz_helper...) to deconfigged. I just do a simple find/replace with deconfigged_helper for *_helper and fix immediate issues where I can (for instance .load(..., format='...') instead of config.load_data).

A number of tests fail for each config, specifically:
cubeviz: 32 failed, 90 passed, 16 skipped, 629 warnings, 4 errors (23%)
imviz: 48 failed, 49 passed, 11 skipped, 494 warnings, 115 errors (44%)
rampviz: 11 failed, 1 passed, 2 skipped, 205 warnings, 0 errors (79%)
specviz: 89 failed, 71 passed, 2 skipped, 862 warnings, 0 errors (54%)
specviz2d: 6 failed, 20 passed, 7 skipped, 95 warnings, 0 errors (18%)
(see attached files for pytest outputs)

A majority of the failing tests have to do with accessing viewers inside the tests. For instance, imviz_helper has a _default_viewer_reference_name attribute that doesn't exist in deconfigged, so deconfigged_helper._app.get_viewer(...) will fail. I tried the following fixture workaround:

@pytest.fixture
def default_viewer(deconfigged_helper):
    """Provide a convenient default viewer wrapper for tests.

    Returns the ViewerWindow user_api for the app's first viewer and also
    attaches the wrapper object to ``[config]_helper.default_viewer`` so legacy
    code that expects ``[config]_helper.default_viewer._obj.glue_viewer`` continues
    to work.
    """
    from jdaviz.configs.default.plugins.viewers import JdavizViewerWindow

    app = deconfigged_helper._app
    # get the first configured viewer reference name
    ref = app.get_viewer_reference_names()[-1]
    viewer = app.get_viewer(ref)

    wrapper = JdavizViewerWindow(viewer, app=app)
    deconfigged_helper.default_viewer = wrapper
    return wrapper.user_api

But this doesn't fix every situation, so I've left it out of the tests for now. I've added a conftest.py to each config directory that should have the CI skip failing tests, with the intention of fixing them ASAP.

Fixes #JDAT-6056

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?
• If new remote data is added that uses MAST, is the URI added to the cache-download.yml workflow?
• 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)?

[kecnry]

is this used anywhere or was just an attempt that didn't work out?

[jbchampagne]

It's not actually used anywhere, but it does work. @MatthewPortman suggested not to implement it until we find a more permanent solution for the deconfigged tests, but I wanted to propose it as a potential solution anyway

[kecnry]

interesting - I just worry this might obfuscate it a bit for us to remove them. Could we just explicitly add the decorators to the tests ourselves or have a commit that reverts those back to the original helpers (so we can clearly see in the tests which still need migrating/fixing)?

[rosteen]

Am I seeing correctly that there are ~300 new test skips here? I feel like we should delay merging this until 5.1 is released so that we have time to work through the failures after that, given that I wouldn't want to continue development and release with that many tests being skipped.

[kecnry]

~300 new test skips here

That is a lot if we aren't going to prioritize this immediately. @jbchampagne - would it be a lot of work to just revert the changes to those tests (back to their individual configs) so that we can still merge in the ones that were able to map over cleanly already?

[kecnry]

do we still need these files?