Make better use of Time's double-float64 internal structure

This a fork of #357, especially regarding this example:
```python
>>> t_utc = Time(range(1960, 2001), format='jyear', scale='utc')
>>> t_tai = Time(range(1960, 2001), format='jyear', scale='tai')
>>> dt = t_utc - t_tai
>>> dt.sec
array([  0.94413024,   1.41749382,   1.8458579 ,   2.256107  ,
         2.76644169,   3.43980608,   4.31317   ,   5.25989779,
         6.20662621,   7.05335392,   8.00008171,   8.94681013,
         9.99999982,  11.74999976,  12.9999999 ,  14.00000013,
        14.99999973,  15.75000007,  17.0000002 ,  17.99999981,
        19.00000004,  19.00000004,  20.00000027,  20.99999988,
        22.00000011,  22.00000011,  22.99999972,  22.99999972,
        23.99999995,  23.99999995,  25.00000019,  25.99999979,
        25.99999979,  27.00000003,  28.00000026,  28.99999986,
        30.0000001 ,  30.0000001 ,  30.9999997 ,  31.99999994,  31.99999994])
```
This snippet shows that the resolution of the Time object resulting from the `UTC->TAI` transformation is roughly of a tenth of a microsecond, which is (roughly speaking again) what one would expect from a single `float64` for modern time JDs.

This is mainly caused by the Sofa library: although it allows to use 2xfloat64 as input and output, it is up to the user to apportion them in a way that preserve accuracy, and the output of a function is not always well suited as input for the next one. This is especially the case for Sofa's function `iauEpj2jd` (the one that is involved in the particular example above), as this function returns two float64 that (for modern times) are of equivalent magnitude, reducing the overall resolution of the whole.

It's not a real problem when coding with Sofa in `C` because the user has full control over input and ouput, but as `astropy.time`   hides all this machinery into its semi-opaque classes, it may be necessary to add some "smartness" in it to make full profit of the two-floats thing.

I may try to work on this but first of all I'd like to know if there's (at least) someone else that agrees this is a problem.