This is not meant to be the last word for backwards compatibility. In
fact, it's really only the first word. There's a lot more work to be
done and more thought to be given to the mechanisms that are required to
support this kind of behavior. Also, this particular case isn't even all
that critical--it just serves as a potentially useful example.

This was necessary since the obsgeovel and obsgeoloc fields were
affected by the schema version change but are not used in Galactocentric
frames, so were not previously being tested.

ASDF should not fail to read a file, even if the file makes reference to
schema tags that are not defined. In these cases, ASDF should simply
provide a raw Python object that represents the deserialized object.

This is an important case that is not currently handled properly.
Currently if an exact version match is not found for a schema version,
the "best match" is used. However, the tag implementation for this "best
match" may not be compatible with the given schema version, which will
result in an unhandled error. This needs to be handled properly.

This will allow us to isolate the error that is caused when an
incompatible tag class is used to implement a mismatched schema
version and reflects the correct behavior in the long run.

All classes that inherit AsdfType are automatically added to the
internal list of built-in types. In this case, adding a type that was
defined within a unit test to the list of built-ins caused problems for
the schema validation tests. This commit is really just a work-around
for now. In the long term, there should be another class that can be
inherited by both built-in and user-defined types.

This seems like the most logical place to make a decision about whether
to write a custom data structure or possible or just return a raw Python
object. Added a new method to AsdfTypes `version_is_supported` to
determine if a particular tag version can be handled by the class. It's
mostly just a stub for now but logic will be fleshed out soon.

This update allows extension types to be differentiated between those
that ASDF provides as part of the library, and those that are
user-defined. The ASDF types are automatically added to the list of
built-in extensions used by the library, whereas user-defined types are
not.

Custom extension classes can now declare explicit support for various
schema versions using the `supported_version` field. If this field is
provided by an extension class, it will be used to determine whether that
class can be used to convert a particular version of a schema to/from a
custom class. If the field is not provided, or if a particular schema
version is not listed, the extension class will simply return raw Python
data structures representing the schema.

This update allows a single extension class to support multiple versions
of the same schema tag. There might be a better way to do it in the long
run, but this way appears to work, at least for built-in classes. It
would require a different mechanism to be used for user-defined classes,
which is problematic.

In order to correctly implement multiple supported versions of tag
classes for all extensions and not just ASDF built-ins, the logic for
adding versioned extension classes was moved from the AsdfType metaclass
constructor to the constructor for AsdfExtensionList. This allows both
AsdfType and UserType sibling version classes to be properly handled.
The sibling version classes themselves are now created within the
ExtensionType constructor and are stored as property of the main version
class.