live-preview marks based on mouseover

[kecnry]

Description

This pull request modifies the previous plugin_opened logic (which only triggered when a plugin was opened in the tray) that controlled the visibilities of "live-preview marks" from plugins to instead be triggered based on whether the mouse is actively over the plugin. A switch (which defaults to false in most cases) can then be toggled to make the live-preview marks persistent and remain visible when the mouse leaves the plugin. Internally, the plugin is considered "active" (and live-preview marks shown) whenever the mouse is over the plugin OR persistent_previews == True.

This includes a visual cue when the plugin is considered "active" matching the color of the live-preview marks (if/when we support customizing the color of the marks, this highlighting should also adjust to match).

Screen.Recording.2023-07-11.at.8.59.09.AM.mov

For spectral extraction, which already used mouseover location to determine which section is active, additional visual cues are added:

Screen.Recording.2023-07-11.at.9.19.25.AM.mov

Lastly, for any plugin for which plugin.has_previews == True, this exposes a temporarily_show_previews context manager that can be used for workflows in the API:

Screen.Recording.2023-07-11.at.9.20.44.AM.mov

This PR affects the following plugins:

• line lists: redshift information updates whether the plugin is opened or not (regardless of mouseover location). This section of the code is now also optimized to use send_state (see replace all hacky traitlet replacements with send_state #2285) to avoid any unnecessary lag.
• markers: the visibility of markers and the "m" keypress event are controlled by the active state of the plugin, this plugin therefore sets "persistent_previews" to true by default, and includes a warning that they keypress is disabled if the user sets to false.
• plot options: stretch histogram is first created whenever the plugin is first opened in the tray or via plugin.show(), but is then updated regardless of the plugin's active status.
• compass: the compass image is first created whenever the plugin is first opened in the tray or via plugin.show(), but is then updated regardless of the plugin's active status
• line profile XY: the "l" keypress event is now always enabled, regardless of whether the plugin is opened in the tray. (Previously it was only active when opened in the tray, meaning it would not work for popups/inline plugins if closed in the tray).
• line analysis: continuum preview marks are visible based on the plugin's "active" status, but the results table continues to update regardless. plugin.show_continuum_marks() which used to allow showing these marks from the API is now deprecated, in favor of using plugin.persistent_previews = True or with plugin.temporarily_show_previews():
• spectral extraction: preview marks are visible based on the plugin's "active" status. Previous behavior with respect to different active sections in the plugin remains, with new visual cues.

Development considerations:

• when a plugin implements preview marks, it should set self.has_previews = True and pass :has_previews="has_previews" :plugin_active.sync="plugin_active" :persistent_previews.sync="persistent_previews" to j-tray-plugin (as indicated in the developer docs). It should then observe the show_previews traitlet to control the visibility of any marks.
• when a plugin wants to defer initializing a component for efficiency purposes, it can observe the plugin_opened_in_tray traitlet but will also need to override plugin.show to handle the case where the plugin is first opened from the API (as is done here for plot options and compass).

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.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[kecnry]

Alternative options:

• use mouseover to consider active state for popout/inline instances of plugins, but being open in the tray is active regardless of mouseover
• have the plugin send pings back to python and consider a plugin active if it has received a ping recently (so once closing all instances of the plugin, it would be considered inactive after a fixed delay). Implemented in plugin active status based on pings #2295.