Add CartesianFrameAttribute to coordinates for GCRS and PrecessedGeocentric frames - #5196

@StuartLittlefair - I still think using a CartesianRepresentation would be much more logical; I'm less worried about code changes than the fact that you mention that examples would no longer be correct. Could you point me to one?

If we're sticking with using some sort of Quantity instead of a new frame attribute, my preference would be to adapt QuantityFrameAttribute's shape-checking. E.g., one could redefine the shape as follows (which is backwards compatible):

shape : tuple of tuple and slice, or None
    The first tuple gives the shape that the particular slice of the input's shape has to match.
    If no slice is given, the whole shape should match. E.g., ((3,), slice(0, 1)) would ensure
    that the first dimension of the input is 3, while `(3,)` would ensure that the input is
    one-dimensional with size 3.
...
if shape is not None and not isinstance(shape[0], tuple):
    shape = (shape, slice(None))
self.shape
...
if self.shape is not None and value.shape[self.shape[1]] != self.shape[0]:
   raise ...

@mhvk I suppose "broken examples" was a poor choice of words.

What I meant was that the representation of SkyCoords with obsgeoloc properties would change, which would change a lot of the documentation and doctests (e.g http://docs.astropy.org/en/stable/coordinates/solarsystem.html)

Beyond that, although I would consider it an API change to transition these attributes to CartesianRepresentations it might be reasonably low impact, since it would only affect users who have created frames using these attributes directly (for example someone who'd written code similar to that in https://mail.scipy.org/pipermail/astropy/2015-September/003912.html) or those who have accessed the obsgeoloc attributes expecting them to return Quantity instances.

If people agree this is acceptable I'm happy to change this to use CartesianRepresentations. I agree it's more logical.

Another advantage of using CartesianRepresentationFrameAttribute is that its shape would automatically exclude the leading 3, so that one can easily check whether it broadcasts correctly against, e.g., the coordinates proper (of course, in your approach you can also expose the shape without the leading 3, but it would mean extra hacking).

@mhvk I've just made a separate PR using CartesianRepresentations. I was surprised how smooth it was in the end. I shall keep this one open until the other is merged.

Closing in favour of #5207