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 think we can still put transforms in its own namespace, and just start filling it on an as needed basis with things we need for WCS.  We'd still have some things in the wcs namespace for the high-level description, but the individual transforms that make them up would be in a different namespace.  I think we can start by putting the low-level arithmetic transforms that are pretty uncontroversial, and the FITS WCS projections, and the various "utility" and composition things that are being discussed today in the e-mail thread.  That should probably be a large fraction of what we need for WCS.  Then at some later date when we have a non-WCS use case for that we can start thinking about more esoteric things.

I'm with you that we can't afford to bikeshed forever, and we shouldn't try to be "complete from the start" like the original FITS WCS standard tried to be.  If we are careful with namespacing and versioning, we should be able to evolve things over time.