Implementation of frames/low-level classes

This PR implements the APE5 api for the low-level classes.  There are a few things that might be improved, and some deviations from the API I was forced into upon trying to implement.  All are detailed below.

At his point, all of the APE5 API is working except the high-level part.  You can check that by doing:
``python setup.py test -t astropy/coordinates/tests/test_api_ape5.py``

cc @astrofrog @taldcroft @mhvk @Cadair @adrn

Changes from API plan:
* It's not currently possible to do ``ICRS(1*u.deg, 2*u.deg)`` - you have to do ``ICRS(ra=1*u.deg, dec=2*u.deg)``.  There's a variety of reasons for that on the implementation side... it's *possible* but a bit awkward to get around that.  I'd say it shouldn't hold up this PR/the main PR, but could be added later.
* `frame_attr_names` is now a dict, not a list.  It maps attribute names to their default values.  It shouldn't actually affect anything too much, because iterating over it still gets the names of the attributes.  But it is slightly different from what the API implied.
* This isn't exactly a "change", but it is something not clearly discussed in the API.  Transformations that are more than one "hop" now have to make an assumption about what the intermediate frame attributes should be.  As it stands right now, they just use any attributes in the `to` frame if they overlap, and otherwise they just use defaults.  To control this better, I also added a `GenericFrame` that will allow the high-level class to set *all* frame attributes for intermediate transformations stages. 

Improvements needed:
* The docs aren't changed at all - will need to do this before a release, but not crucial for the implementation.
* `__repr__` (and `__str__`) aren't great - I think @mhvk was going to work on this for the representations?  Perhaps with some delegation there, this can be substantially improved.  It's not crucial that it be *really* good, because that's really the domain of the high-level class, but I think it's be nice if it's at least comparable to numpy arrays or similar.
* `__eq__`, `__len__` and such are all missing.  This isn't necessarily critical, but we probably want at least some of those.  But they're not in the representations, so we need to decide what to do about them.
* The accuracy tests need to be updated for this scheme... So there could be some accuracy issues, although I took the algorithms straight from the old implementations, so they *shouldn't* be different (famous last words...)