Support Asset priorities and cancellation

## What problem does this solve or what need does it fill?

I'm building a map app with Bevy and I have built two custom `AssetReader`s and I end up loading a lot of assets with them. I have hit two separate but closely linked issues that I think could be common for Bevy's use cases and therefore might be worth solving within Bevy itself.

1. When an asset that is being loaded is orphaned it continues loading to the end.
2. Sometimes you want to prioritise certain assets over other ones, essentially assets closer to the camera need to be loaded first.
3. (Optional yet closely linked with the other two.) At least for loading assets over the network (as in my case) you often need to limit how many loads are happening concurrently, it also brings needs for retries.

## What solution would you like?

1. I'm not that familiar with async in Rust but in Go and JavaScript it's common to pass a "cancellation token" to async functions which they themselves can then check for cancellation ([Go has Context](https://pkg.go.dev/context#Context) and [JavaScript has AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)). Obviously the choice should be something that is well supported in the Rust async ecosystem. Looks like Tokio has [CancellationToken](https://docs.rs/tokio-util/latest/tokio_util/sync/struct.CancellationToken.html).
2. An `Option` (or `f32` with default of `f32::NEG_INFINITY`) attached to assets and a new `load_with_priority` method for loading. Then when picking assets for loading sorting them and starting with assets from the highest priority. I don't know how the internals for asset loading works but seeing that there is a `LoadState::NotLoaded` I assume it shouldn't be that complex.
3. A trait (?) that returns an "`AssetGroupId`" and an "`AssetConcurrencyLimit`", or something like that? This requires quite a bit more design if this is something Bevy would want to implement.

## What alternative(s) have you considered?

I implemented these all with my own components and systems that only support the exact use cases I need in my app which works for me.