Follow-on to 2586

This PR makes a variety of changes (due) to the mutable `representation` features introduced in #2586.  There are 4 changes that are probably not too controversial (unless @taldcroft has an objection):

*  `default_representation` and `frame_specific_representation_info` are now turned into read-only properties in the metaclass `__new__` (so now the `frame_specific_representation_info` is public, @taldcroft)
* Adds a few docstrings for frame properties (for ipython ``?`` usage) and some similar other cosmetic changes
* changed `representation_names` to `representation_component_names` and `representation_units` to `representation_component_units`.  The original names were quite ambiguous (at least `representation_names` was - the first time I tried to use it I mis-used it because I thought it was the name of the representation...)
* Changes how `frame_specific_representation_info` is defined.  This is something like the spirit of #2626, but is implemented somewhat differently due to the need to be inside a dictionary. See the diff in `builtin_frames.py` for exactly how it looks. The most crucial elements this adds is that the frame name and representation name now appear right next to each other - right now I think it's highly error-prone to have only the frame name and not the representation name. (This is actually putting this  *back* in, as a slightly less clear version of this was in prior to #2586 )

A final change that might be a bit more controversial (for @taldcroft, @Cadair, or @vaticancameos ?):

* This removes the `default_names` and `default_units` from representations, and puts back in explicit `frame_specific_representation_info` everywhere.  I think this is *very* important.  There are plenty of frames where spherical coordinates are *not* called RA/Dec, and the whole point of APE5 is to cleanly separate representations and frames (and SkyCoord).  Adding `default_names` that are different from the actual component attributes blurs these lines and I think makes things a lot more confusing.

@taldcroft et al., if this is all ok with you, I'll do a more careful look over the docs to ensure there aren't inconsistencies this introduces, but other than that it should be good.  It almost certainly will conflict with #2626 though, so that should go in before this.

oops, yeah, as you surmised that's incorrectly in there from the rebase - will remove. (and the docs in the above comment)