Asset file name extension handling should be consistently case-insensitive

[BenjaminBrienen]

I want to argue that the previous behavior was actually better (even though it seems inconsistent at first) 🙈.

My argument rests on three points

1. that it's more convenient from a user's perspective, for the extension to be case-insensitive
2. that it's more convenient from a plugin author's perspective
3. that there is no good use-case for needing case-sensitive extensions

From a user's perspective: if my assets are coming from a third party, I may not have control over the case of the file extension.
Example: some STL files in this repository use an uppercase extension, others use lowercase (example shared by @dlhxzb in nilclass/bevy_stl#17).

Similarly when collaborating with people who work on systems with case-insensitive filesystems, asking them to use a consistent case for the extension can create unnecessary friction.

From a plugin author's perspective: suppose I want my users to be able to load files with any case (e.g. *.stl files and *.STL files as in the example above), then I would need to specify ["stl", "STL"] as the list of supported extensions.
Once I do that though, one could argue that *.Stl should be supported as well. So do I add that to the list too?
Ultimately that decision will be up to the plugin author, so case-sensitivity of file extensions would not be consistent across the bevy ecosystem, as some authors may support only uppercase extensions, while others support only lowercase extensions, while others would support some combination.

This leaves the question: is there a good use-case for case-sensitive extensions?
I can find some examples where it is, but I'd argue they are esoteric.
Looking at the spec for shared-mime-info's "glob" attribute, it matches extensions case-insensitive by default, unless explicitly requested:

Applications MUST match globs case-insensitively, except when the case-sensitive attribute is set to true. This is so that e.g. main.C will be seen as a C++ file, but IMAGE.GIF will still use the *.gif pattern.

Looking at the actual usage of the case-sensitive attribute in the freedesktop.org database, there are just a few entries:

$ grep case-sensitive /usr/share/mime/packages/freedesktop.org.xml
<!ATTLIST glob case-sensitive CDATA #IMPLIED>
    <glob pattern="core" case-sensitive="true"/>
    <glob pattern="perf.data" case-sensitive="true"/>
    <glob pattern="*.C" case-sensitive="true"/>
    <glob pattern="*.c" case-sensitive="true"/>
    <glob pattern="*.gs" case-sensitive="true"/>

None of these look relevant for the bevy asset loader.

Finally, what about @NiklasEi's original issue, of registering an asset loader for the Custom extension?
I think this could be solved, by:

1. Documenting that AssetLoader.extensions should return all-lowercase strings
2. (optionally) Logging a warning if an AssetLoader specifies an extension that contains uppercase characters, pointing to the documentation

Originally posted by @nilclass in #17065 (comment)