0.12 - Method for us to obtain asset `root_path`

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

tldr; In 0.11 there was a way to obtain the root path for assets from code, but now it is not possible AFAICT.

I'm building a game that I require to be flexible for expansion. So in 0.11 I had code that searches the asset directory for all "registry files," so that mod/expansion content can simply be added as folders to the assets directory. This was done by getting the `root_path()` from `FileAssetIo` and then using the `glob` crate to search for `"**/*.reg.toml"` and load these files.

However, in 0.12 `AssetIo` was replaced with `AssetSource` and `AssetReader`. I'm excited for this change, but we also lost the ability to downcast `AssetReader`, so even though `FileAssetReader` has the `root_path()` method, I have no means of actually calling this function, and I am unable to migrate my code to 0.12.

## What solution would you like?

I would like to add the `Downcast` trait to `AssetReader`. I'm not the only one to miss this functionality [\[1\]](https://discord.com/channels/691052431525675048/1171470656894947379), and I think it would be useful for many different plugins. The downside to this is that it would technically be a breaking change of anybody implemented an AssetReader, and probably shouldn't
be in a 0.12.x release

## What alternative(s) have you considered?

### Add `(prefix?_)root_path` to AssetReader, AssetSource, or AssetServer

For AssetReader: While not every implementation would return a path (for example, `embedded`), we could make AssetReader return an `Option<&Path>`. This way we could unblock me on 0.12 migration, and by making it return `None` by default we could make it not a breaking change and hopefully make this into a 0.12.X release so I don't have to wait until 0.13 to migrate. The downside is that other people might have different reasons for wanting to downcast AssetReaders, and this wouldn't really solve it for them.

For AssetServer/AssetSource: It would be nice if I didn't have to dig so deep in the type tree to get this information and was just able to get it from an AssetServer directly. It would also make it more likely that we don't lose this functionality in the future. However this does sort of feel like "exposing internals"

### `load_glob()` for AssetServer

This technically doesn't allow us to obtain a `root_path`, but it would solve my personal problem perhaps more elegantly than simply being able to obtain the root path again. It could behave similarly to `load_folder`, but allow us to specify things more dynamically. I can see this being a very useful tool for

Unfortunately, this would probably be pretty complicated. For file assets it might be less complex, but for other AssetReader's it would be more complicated. How would this work for a network AssetReader, or embedded? If these asset readers had a list of all paths available to them then we could use a crate like `glob-match` or `wax`. If we leave it to individual AssetReaders to sort out, then that's quite a major task we've suddenly given them. We could make it so only some AssetSources support it, but that can be hard to communicate to users why` "embedded://foo/**.bar"` isn't working.

## Additional context

* Attempted help discussion [\[2\]](https://discord.com/channels/691052431525675048/1171283445939449959)

Start by reading AssetReader, AssetSource, AssetServer, and FileAssetReader in the asset subsystem, then compare the 0.11 FileAssetIo behavior with the 0.12 reader API. Determine which supported API should expose filesystem roots or equivalent asset discovery, and define compatibility coverage for file and non-file asset readers.

Written by the indexing model from the issue text.