Add viewer.get_viewport_region method

[bmorris3]

Description

Introducing: a method on the imviz image viewer get_viewport_region which returns a PolygonSkyRegion that outlines the imviz viewer. This PR is the jdaviz-side implementation of spacetelescope/mast-aladin#71. Together, we can use these to show one app's viewport limits in another app (specifically: jdaviz <-> mast-aladin).

Test it locally with this in one cell:

from jdaviz import Imviz
from jdaviz.conftest import _image_hdu_wcs

image = _image_hdu_wcs()

viz = Imviz()
viz.load_data(image)
viz.show()

Then run

# PolygonSkyRegion that traces the outer limits of the viewport:
region = viz.viewers['imviz-0'].get_viewport_region()

# load that region back into the viewer to check it:
footprints = viz.plugins['Footprints']
footprints.keep_active = True
footprints.import_region(region)

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.64%. Comparing base (fbcabce) to head (6616a59).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3851      +/-   ##
==========================================
+ Coverage   87.63%   87.64%   +0.01%     
==========================================
  Files         188      188              
  Lines       25703    25725      +22     
==========================================
+ Hits        22524    22547      +23     
+ Misses       3179     3178       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kecnry]

A few thoughts...

• Would it ever be useful to get pixel coordinates of a specific layer with this as well (obviously pixel coordinates of the reference layer are the same as the axes limits)?
• This is slightly different, but not all that different, from get_viewport. This returns the corners instead of center and radius, but doesn't have the flexibility mentioned above to request a specific layer or toggle between sky and pixel coordinates. Do we want to somehow merge these or include corner information in get_viewport (modulo my next concern)
• This will be susceptible to multiple widget instances of the same image viewer and I think will just return the corners of the most recently focused viewer (but we probably should confirm that). Is that ok? Do we need to explain that anywhere or is in self-explanatory?

[bmorris3]

Good Qs @kecnry:

I'm sure someone could find a use for pixel regions as well, which is just the first half of get_viewport_region. I gave it this name specifically because it would return a region, and maybe I should have further specified get_viewport_sky_region. I'm happy to change the name, or implement the pixel region option. Just wasn't part of our scope.

This will be susceptible to multiple widget instances. The Cobalt workflow that uses this method, showing a jdaviz viewer's footprint in another app, will always occur in a crowded jupyterlab workspace, where it would be hard (though not impossible!) to have multiple views of a widget.