Drop old asdf versions in compatibility tests

[braingram]

#2002 worked around an issue with the newest setuptools no longer providing pkg_resources (which asdf <=2.13.0 requires).

I think we can consider dropping some of these versions from the tests since even 2.13.0 is roughly 4 years old. The issue addressed above will likely come up again with a different dependency or python version change.

One alternative for at least the "can we read old files" test would be to save versions of files generated by the older versions (rather than regenerating them each test run as is done now). This is only a partial alternative since tests that confirm the old version can read the new files cannot use a similar approach.

Perhaps we can establish a reasonable policy for dropping testing of old versions. Something like:

If the old version is more than 3 years old (following the more strict python version support recommendation from https://scientific-python.org/specs/spec-0000/) then if the tests start failing due to environment resolution we can drop testing.

If we make a change that results in failure to read an old file (let's say one from 2.7) users can install an intermediate version (for example 2.15) and rewrite the files to get them working in the latest version.

[zacharyburnett]

I like the idea of adding a clear deprecation or "back-support" policy for each version. If we keep an archive of old files from previous versions then we can also update the list of tests and advance xfails accordingly in each successive version

Then, we can have a set of "supported standard versions" for each released library version