Imviz helper: rename offset_to to offset_byand have it use units

[eteq]

This is a simple follow-on from #687 - I failed to review in time, but fortunately had one-and-a-half minor change to sugges (i.e., just changes in offset_to):

1. I think the offset_to helper method on Imviz is better named offset_by. This aligns better with astropy.coordinates and I think it makes it just a bit clearer that you are giving the delta coordinates instead of actual coordinates
2. I think we can dispense with the skycoord_offset keyword by instead using the units of dx/dy - if they are either pixel or dimensionless that can be interpreted as pixel offsets, and any other unit can assume SkyCoord/other WCS ("other wcs" can be implemented in the future, but I'm just trying not to accidentally specify ourselves out of it)

[pllim]

Re: to vs by -- That is inherited from both astrowidgets and your original idea. If you want to rename it, it has to happen in astrowidgets first.

#687 (comment)

https://github.com/astropy/astrowidgets/blob/ace5abb820c030122add475ecf106114aaa68e1b/astrowidgets/core.py#L346

https://github.com/eteq/nb-astroimage-api/blob/ee6f0a30673b11c0c68192c6c2fd1dfa47ceb23c/minimum_viable_imagewidget.py#L53

[pllim]

As for changing the API, I think it also has to happen in astrowidgets?

[eteq]

Yeah I suspect it was my fault 😉, but I do think this is a good opportunity to review these decisions.

I'd argue for this:

1. We do the fix above in jdaviz now, but with a offset_to shim that respects the "old" API
2. We make a fix in astrowidgets along the lines of what I was saying, with a deprecation warning for offset_to.

[eteq]

Although, maybe I should have reversed the order? I guess I could see it either way, depending on what you think @pllim

[pllim]

As discussed offline, I prefer the change to happen upstream first, so we do not set the precedence that it is okay to diverge from the astrowidgets API as we like.