Integrate `Source`/`Resource`/`Subresource` framework with `resourceIndexer`/`ResourceVersions`/`ListResources` framework

[tsibley]

A big tension between the Source/Resource/Subresource framework and the resourceIndexer/ResourceVersions/ListResources framework is that the former is built around dynamically-constructed URLs (relying on, e.g., conventions and external queries) while the latter is built around statically-constructed and stored URLs.

The point they interact—Subresource.url() calls Resource.versionInfo() which uses Resource.versionDescriptor—is awkward and ill-fitting because of this tension. These two very different ways of doing things collide and subvert each other. For example, a Resource without a versionDescriptor represents the “latest” or “live” version of the resource, while one with a versionDescriptor abdicates behaviour entirely by jumping out of the Source/Resource/Subresource framework and into ResourceVersions and the resource index framework.

It would be clarifying to intentionally do things just one way. Either:

1. Move past version handling into Source/Resource/Subresource framework.

   ResourceVersions/ListResources go away and become part of Source/Resource instead as new methods and logic. Possibly an additional ResourceVersion (singular!) class in the hierarchy as a way to separate concerns about a resource as a whole (i.e. with many versions) from its specific versions.

   This doesn’t preclude statically-constructing indexes of our resources; it means that indexes are built and used as part of the dynamic construction approach. For example, resourceIndexer would make (partial) use of Source/Resource/Subresource classes. In Nextclade dataset reference trees #1249, I did a very little bit of this with the indexer using NextcladeSource.

or

2. Move all version handling, including “latest” (i.e. no version descriptor), into resourceIndexer/ResourceVersions/ListResources framework.

   Source/Resource/Subresource stop dynamically constructing URLs and always consult the resource index. The resource index in turn needs to become more dynamic and be able to be updated in a more timely manner.

   This effectively makes the resource index much more like a live database we query as the source of truth.

Pragmatically, it's likely easiest to start with (1) so that we don't have to improve the indexer's lag time right away. Doing (1) first does not preclude moving to (2) further down the road (and probably makes it easier).

[tsibley]

Related weirdness because the way we handle current vs. past versions are not conceptually integrated:

• [resource versioning] Interaction with PUT/DELETE/OPTIONS methods is likely wrong #744