`Time` values do not always round trip perfectly

Due to how we are generating the representation for `astropy.time.Time` objects, some numerical inaccuracies accumulate. This results in the time value read from asdf for a `astropy.time.Time` object slightly differing the value of the original object. The reason for this is that several of the available time `formats` require a conversion into a format which we write to ASDF (for human readability) and then that `format` will get converted to the original format, which is a process that generates numerical errors.

A demonstration of this is the need for a `atol` and the use of `isclose` instead of `==` in this test:
https://github.com/WilliamJamieson/asdf-astropy/blob/889005badaea78a6feb59f72574d3b9b299292b9/asdf_astropy/converters/time/tests/test_time.py#L139-L153 (fixing an incorrectly written test as part of #132).

Currently, there are two possible solutions that I see:

1. `astropy.time.Time` should be written under a new schema (say `http://astropy.org/schemas/astropy/time/time-1.0.0`) rather than the one built into ASDF. This schema should instead write the base-representation (using `val1` and `val2` directly) for the `astropy.time.Time` object rather than attempting to write the object in a human-readable format. @perrygreenfield suggested that maybe ASDF should support converters including a comment alongside this to make it human readable.
2. As proposed by @eslavich, use the `decimal` built-in type of `python` to exactly convert `val1` and `val2` into their exact representation for the universal time value, and write that value as an exact string. Then forcing the read in `decimal` followed by a computation in `decimal` to extract `val1` and `val2`. Maybe include a flag in the existing `time` schema to indicate this mode should be used.

Other solutions may exist, which should be discussed as part of this issue.

Start with asdf_astropy/converters/time/tests/test_time.py, especially the linked round-trip test around lines 139-153, and review how astropy.time.Time values are represented and read. Compare the existing time schema behavior with the proposed base-representation and decimal approaches. Done means Time values round trip without numerical inaccuracies and the tests verify exact equality where appropriate.

Written by the indexing model from the issue text.