Make coordinates array-compatible

At long last, this PR renders it possible to use array `Angle`s in `coordinates`. It also includes tests of all the builtin transforms using arrays.  It builds off all the work that has recently gone into `Quantity`, `Angle`, and `Distance` to make this possible.

@astrofrog may want to take a look in particular on the E-terms conversion (for FK4) - that required some re-writing of the transformation because as originally written, the arrays were not aligned in a way that's compatible with more than 1D arrays.  I *think* I got everything right, but you may want to double-check me there.

In this PR, one can create array coordinates using all of the syntax as previously, but with arrays or lists instead of individual numbers/strings.  The notable missing feature is creating array coordinates using a *single* list of strings.  E.g., ``ICRSCoordinates(['1h2m3.4s 5d6m7.8s', '10h20m30.4s 50d60m70.8s' ], unit=(u.hour, u.degree))`` does *not* work.  I did not do this because #1421 still needs to be resolved, which has direct impact on how the above gets implemented.  And there's no reason this can't be added in a follow-on PR, as it isn't used internally anywhere.

The other possibly missing feature is support for arrays of `obstime`.  This is not in both because the implementation is somewhat different from the other aspects, and it's not clear that `obstime` will be included in this way in future iterations of `coordinates`.  It might actually just work in many cases, but no checking is currently performed (unlike for the angles and `distance`, if there is one)

cc @taldcroft @adrn @demitri

Note that this will close #884 when merged.