Add more load_direct implementations

[ricky26]

Objective

• Introduce variants of LoadContext::load_direct which allow picking asset type & configuring settings.
• Fixes Add LoadContext::load_direct_with_settings or similar #12963.

Solution

• Implements ErasedLoadedAsset::downcast and adds some accessors to LoadedAsset<A>.
• Changes load_direct/load_direct_with_reader to be typed, and introduces load_direct_untyped/load_direct_untyped_with_reader.
• Introduces load_direct_with_settings and load_direct_with_reader_and_settings.

Testing

• I've run cargo test and played with the examples which use load_direct.
• I also extended the asset_processing example to use the new typed version of load_direct and use load_direct_with_settings.

---

Changelog

• Introduced new load_direct methods in LoadContext to allow specifying type & settings

Migration Guide

• LoadContext::load_direct has been renamed to LoadContext::load_direct_untyped. You may find the new load_direct is more appropriate for your use case (and the migration may only be moving one type parameter).
• LoadContext::load_direct_with_reader has been renamed to LoadContext::load_direct_untyped_with_reader.

---

This might not be an obvious win as a solution because it introduces quite a few new load_direct alternatives - but it does follow the existing pattern pretty well. I'm very open to alternatives. 😅

[alice-i-cecile]

Generally very happy to see these added. I agree with you on the API explosion here 🤔 IMO we should 1) make sure to just call the most general form with null params from all of the other related methods to avoid messy/error-prone duplication 2) consider using the builder pattern in some form (load_direct(foo).with_settings(settings).with_reader(reader)) to avoid the combinatorial explosion.

2 is just an idea: if you can't find a nice way to make the code work I won't block on it.

[ricky26]

@alice-i-cecile I've had a go at implementing a builder-style API. I suspect this is more open to bike-shedding (in particular .load_direct().load() isn't my favourite), and more likely to have other issues. However, I did the simpler tidy-up in the prior commits, in case this proves to be more controversial.

[alice-i-cecile]

Hmm, I don't think that's an improvement 😅 Neat to see, but I would probably revert the builder experiment. I'll ask folks for more opinions / ideas.

[bushrat011899]

I like the additional flexibility this provides to end users! Just a couple of minor issues I noticed in the documentation I've also noted my personal opinion that this should probably be refactored into the builder pattern, but that is absolutely out of scope of this PR and likely contentious.

[bushrat011899]

Future Work: The LoadContext really needs a builder API:

• load
• load_untyped
• load_with_settings
• load_direct
• load_direct_untyped
• load_direct_with_reader
• load_direct_with_settings
• load_direct_untyped_with_reader
• load_direct_with_reader_and_settings

I feel like calling context.loader().direct().typed::<A>().with_settings(...).load(...) is much friendlier to code completion, and would allow for documentation on each of the individual options in the API.

[ricky26]

I hadn't considered moving the non-direct loads into the "same" builder. Good shout. It's worth noting that specifying type to load with a TypeId but still getting an untyped asset is a useful permutation we still don't have. 😅

[bushrat011899]

It's getting worse by the minute! LGTM before anyone else has any ideas 🤣