GWCS proposal

This is based on the discussion on June 17 regarding dimension mapping and "stages" of a higher-level transformation.  This is just an example WCS -- it's probably fastest to just provide examples and talk about them, and then a schema can be formalized later.

It adds the concept of "steps" to the overall WCS pipeline, and removes the assumption that the transforms are always pix-to-world or world-to-pix.

One advantage of this example is that the overall structure of the transformation (which is unlikely to change for a given instrument/configuration) is separate from the specifics about the parameters on those transformations, which vary for each exposure.  It's still probably more flexible than it needs to be, since you could replace the rotation part of the linear transformation with a skew and which probably wouldn't make any sense...  One could push this idea even further and fix all of the transformation types and provide a mechanism to pass numerical values into an otherwise static structure.

The `in_map` and `out_map` feature here is a hybrid of what's in `jwst_lib.modeling` on every Model, and Erik's proposed concept of naming dimensions.  In working through the example, I didn't have a need for it outside of separable transforms.  I'm starting to wonder if it needs to exist outside of separable transforms.  Even for the case where you just want to swap axes, you can always insert a separable transform, which leads me to think we should just rename it to "axis mapper" and consider it the swiss army knife you pull out when the axes need rearranging.

Anyway, hopefully this can be something concrete around which to have concrete discussion.

@perrygreenfield, @embray, @nden, @bernie-simon
I was about to make a similar comment (I think). Frame references don't always have to refer to all coordinates. Some frames only make sense for spectral coordinate, some only for time, and some only for spatial. I don't think there are many that combine these at the world coordinate system level (i.e., once coordinates map directly to physical quantities). Frames that exist at the detector level (or intermediate levels sometimes) can mix all coordinates so not all Frame references cleanly separate due to physical classification. This argues that there are times when for completely separable coordinates, that independent pipelines of transforms with independent labeling may make sense (I can't say I have a good solution that addresses both cases well).

In the existing proposal, one could analyze the coordinate mappings and see if a certain array coordinate is separable all the way through and thus label it such. (Note, it is possible to camouflage separable coordinate with transforms, e.g., if my detector were perfectly aligned with ra an dec, and yet I applied a rotation at one point, and then the opposite rotation at another, it wouldn't be easy to determine that the coordinates were separable. But this is a perverse case I'm not worried about). This does seem a bit involved but maybe it is workable. In the cases I talk about in the next paragraph, the structures to analyze are not likely complex.

But going in a somewhat different direction, it's probably sensible to consider common cases. The kind I'm thinking of most when it comes to completely separable cases are likely mostly resampled data. In this case the transforms are almost certainly going to be completely separated from beginning to end, and likely comparatively simple (e.g., no complex distortions other than standard projections). Spatial coordinates may still consist of a few transforms involving projections, translations, rotations and scaling, but not much more. Spectral coordinates may have a dispersion transform of some sort and a redshift, but not much more. Time is likely to have just a convention assigned. So in this case, it would be good to be able to identify that the array coordinates (i.e., input coordinates) are separable (e.g., one spatial, one spectral, or two spatial coordinates and one spectral, etc).