Require representation input to be Quantity, and backward-compatibility layer - #26

@eteq - this is almost completely functional, but there are a few test failures. Before I fix them, I just wanted to check whether it's ok for frames to have positional arguments for the coordinates?

I'm working on the failures under the assumption that positional arguments are ok (based on the API document)

So just to be clear, this PR means that:

• Representations have to take Quantity, nothing else (nicer & simpler behavior)
• Frames then by extension can't take anything other than Quantity
• For 0.4, if frames detect a deprecated API use, they will emit a deprecation warning and return a SkyCoord instance.

I believe this actually provides a mostly backward-compatibility layer for 0.4. We could actually try and run the old test suite on it to check.

All current tests pass! A few documentation (rst) tests fail, but the documentation needs updating anyway.

Also, one nice thing here is that the backward-compatibility layer is easy to remove in the next version - we just need to remove __new__ from the base frame class.

Looks generally good, @astrofrog (a few minor comments inline)! But it looks like you did not change CartesianRepresenation to only accept quantities - is that intentional?

@eteq - I can change CartesianRepresentation too - I just hadn't touched it since it doesn't accept strings anyway, but I agree let's go all the way and make it consistent.

Ahh, I see. Yeah, sounds good.

@eteq - hmm, it seems that the code was relying on being able to pass non-quantities to the cartesian class, e.g.:

        #now re-cast into an appropriate Representation, and precess if need be
        if isinstance(fk4noecoord.data, UnitSphericalRepresentation):
>           representation = CartesianRepresentation(x=x, y=y, z=z)

astropy/coordinates/builtin_frames.py:471

Maybe I should revert this change for now? I'm getting 160+ failures now...

In the above case, x, y, and z are plain numpy arrays.

Actually I think the fix is easy...

@eteq - this is ready for review/merging. All tests pass (except a few in the docs, which is to be expected)

Cool, thanks. Merging!