Support >1D tables in TableCoordinate and ExtraCoords

Start by reading TableCoordinate, ExtraCoords, BaseTableCoordinate, and QuantityTableCoordinate, then inspect the linked astropy.modeling.tabular.py _Tabular inverse transform. Compare the three proposed approaches, with particular attention to multi-table world-to-pixel behavior and APE 14 interfaces. Done means supporting >1D tables without the current construction restriction and preserving the relevant coordinate conversions.

Currently (as of #414) we explicitly disable constructing lookup tables (through ExtraCoords or directly) because the inverse transform in the tabular model doesn't support converting from value (world) to pixel. The reason for this is that it is possible for that value -> index (world to pixel) transform can be multi-valued. If there is two values in the table then you can't get a single index out, so the transform is invalid.

There are a few different ways to approach fixing this, the ones that come to mind at the moment are:

• Implement the inverse transform in _Tabular as long as it is singular valued. This would make it work as long as you pass a well behaved table in. The catch to note here is that each coordinate would have to be singular valued (i.e. lat and lon, or x, y and z) not the union of all three. This is because the inverse is called for each coordinate individually. This limitation would be pretty damming for the most common of our use cases.
• Do the above and also refactor QuantityTableCoordinate to only use one N+1 dimension lookup table. This would probably require some special handling if the units on the table are different, and might have some other fun issues which I can't forsee.
• Make BaseTableCoordinate implement both the Low and High level APE 14 interfaces itself. Then we can work around the limitation of the first option by writing our own special cased multi-table world to pixel transform. We could lean on the gWCS coordinate frame machinery to help us out a lot with this, it would really only come down to implementing world_to_pixel and pixel_to_world as all the other stuff (and the values variants of those methods) we could lean of the gWCS coordinate frames for. This would give us the other advantage of being able to pass a BaseTableCoordinate instance right into NDCube without having to do irreversibly convert it to a gWCS first.

The third option is definitely a lot of work, but the first two aren't exactly easy either. I think the third one also gives us some nice secondary advantages, so would be the way I would be tempted to go.