Allow Reader to implement AsyncSeek and provide a way for loaders to "ask" for a compatible reader.

[andriyDev]

Objective

• In Replace AsyncSeek trait by AsyncSeekForward for Reader to address #12880 #14194, we replaced AsyncSeek with AsyncSeekForward. This allowed us to support more kinds of sources, but the cost was that loaders were more limited in what they could do with the reader.
• Archive-like things generally use offsets relative to the start of the file. AsyncSeekForward made it difficult to deal with this (or impossible in some cases).
• This is a step towards Improve support for "random-access" assets (e.g., ZIP files) #21641.
• Fixes AsyncSeek trait bound on Reader may limit options to stream bytes #12880.

Solution

• Allow AssetLoader to say which "features" of a reader it needs.
• Pass that list of features to AssetReader so it can decide how to handle it.
• Add a new AssetReaderError::UnsupportedFeature.

This design is kind of "weak" - there's no guarantee that a loader that requests AnySeek will get a reader that actually implements AsyncSeek. Or on the other side, there's no guarantee that a loader actually requests the features that it uses. However, in practice it's likely enough: errors are likely to guide users to the correct situation. In the future, we could perhaps have a "sieve reader", which blocks any features the loader didn't explicitly request. Perhaps this is a debug only feature, or something that can be toggled.

Testing

• Ran the modified examples. They still seem to work!

[atlv24]

nice job, looks good to me

[cart]

I see the vision, and I think this makes the right UX tradeoff. The alternative is forking out a separate set of AssetLoader traits, which would be a big UX downgrade.

The big "risk" here is that loaders won't request seeking behavior by default, but they will get seeking behavior by default. Then when they are used in a non-seeking context, they will fail at runtime. I expect this to be a common source of bugs in practice.

The big use case here is skipping the intermediate "read into buffer" behavior for the web / wasm providers, when a loader doesnt request seekability. If we start doing that, then loaders that don't request the appropriate feature will fail at load-time. Fortunately, I think this is the kind of thing that will be caught quickly. If/when we land that, we'll probably want a break-glass configuration item that devs can use to force seekability via the intermediate Vec, so they can quickly work around offending loaders they don't control.

I just removed all of the unnecessary "default" impls to cut down on the noise. I also merged with main.