This PR is the fourth (and last ) in a series by @adrn, @mhvk, and myself trying to support velocities in astropy.coordinates. This PR is based on #6219, so will need to be merged after that one, and has a lot of commits from the series of PRs. To see a cleaner diff with just these changes, take a look at adrn#13.

The main purpose of this particular segment of the work is implementing a new transformation that uses finite difference techniques to compute velocities in coordinate frames. It also replaces most of the Astropy transformation machinery to use that new transformation, supporting transforming between the various astropy frames and getting correct velocities out.

It's all working (and there are explicit tests for the main frames of practical use), but there is a flaw: for objects more distant then ~10 kpc, solar system velocity effects (most critically, the heliocentric correction) start getting swamped in machine precision noise because the km-kpc dynamic range is just too much. (This is demonstrated in the test_numerical_limits test). For closer objects this isn't really a problem.

This can be fixed in principal by clever finite difference techniques or even just capping the distance as seen in the finite difference transform. However, the details of this probably cannot be worked out in time for the feature freeze. So I propose (if all is well) merging this (after the remainder of the velocity stack of PRs is in), but also merge an updated version of #5752 (which I can easily get to tomorrow). The docs will reflect this plan in that there will be a big red "velocity support is experimental" warning in the coordinates docs, and the functions from #5752 will also mention that their implementation might change to use the coordinates machinery ones the finite difference issues have been ironed out.

One other change this makes is that there is now a warning for FunctionTransform's that drop differentials. This still allows FunctionTransforms to set differentials themselves, but is there to make it clear that "legacy" FunctionTransforms should be updated to do something with the differentials. This is debatable behavior... it would be easy to just have it silently drop the differentials on the assumption that this is the intended behavior. But I think its better this way to remind anyone whos implemented their own FunctionTransform that they should update it if it will ever be used with differentials.