Spectral extraction in Cubeviz with composite subsets

[bmorris3]

This PR introduces spectral extraction to cubeviz for composite subsets. The implementation converts the composite subset to a boolean mask, and applies it in the NDData collapse. The only supported aperture extraction method is "center," since this approach completely avoids the photutils pixel weighting methods.

cubeviz-spectral-extract-composite.mov

I've added a test that extracts two spectra from individual non-composite subsets, and compares their sum with the spectrum of a composite subset that spans the same area as both subsets combined.

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

[kecnry]

can we instead consider these as valid and add support for showing the orange outline?

EDIT: ah, I see, we definitely want to set something so that this message is displayed in the plugin, and it probably should not be considered a valid aperture for other cases, but it would still be nice if we can visualize the aperture itself 🤔 . The fact that this is a reusable component, also means that we probably should not refer to spectral-extraction specifics in the message set by the component (since this will then also appear in aperture photometry, etc, which won't make any sense).

[bmorris3]

Removed the spectral extraction-specific aperture message in fbbdbd6, the UI warnings now looks like this:

[rosteen]

The diff (minus the tests) is smaller than I expected, nice implementation. It didn't break when I tested and the code looks good to me.

[rosteen]

I kicked the CI to see if Codecov will upload this time, that looked like a transient issue.

[kecnry]

I suspect this will motivate some UI/UX changes when we get to reviewing the plugin as a whole, but agree that doesn't need to be in scope here. I'm still a bit torn on whether we should visualize the selection for this case (and if we don't under the argument that its not exact, then perhaps we should also turn off the aperture visualization when the user turns off exact? - but again, that can be considered later).

[bmorris3]

Thanks both!