Unify asset path seperators for all platforms

[NiklasEi]

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

Currently, Bevy supports both / and \ to load assets. This can lead to surprising paths in asset handles:

(on main 0db999c)

• Load a file with asset_server.load("images/tree.png")
• Load a folder with asset_server.load_folder("audio/background")

Based on the loaded paths I would expect the resulting handles to use / as the path separator on all platforms. On Linux this works as expected.

On Windows, the "images/tree.png" path contains a / as expected. But the handles from the folders contain both \ and / (e.g. audio/background\car.ogg).

What solution would you like?

We should probably only use one separator in asset paths.

What alternative(s) have you considered?

We could use other separators, but / looks like the most obvious choice.

Additional context

There has been some relevant discussion on Discord:
https://discord.com/channels/691052431525675048/749332104487108618/1167563412277047396
https://discord.com/channels/691052431525675048/1164297864441249823

[viridia]

More discussion here: #9528

The plan we discussed is to remove the use of PathBuf internally from within AssetPath and instead implement a Bevy-specific equivalent that would be platform-neutral (perhaps called AssetPathBuf). We would only convert to Path at the last possible moment before interacting with the filesystem.

One option is to simply fork PathBuf and cut out 90% of what it's doing - so it would no longer recognize drive letters, backslashes and so on. It only really needs the basic push() and pop() methods that understand directory separators.

AssetPath has fairly comprehensive unit tests, so this should not be a risky change so long as all the tests pass.

[viridia]

A question: currently Path stores the characters as an OsStr. For an asset path, which is intended to be platform neutral, would it be better to store the path as an OsStr or as a String?

[DasLixou]

Probably #10511 ?

[NiklasEi]

Closing in favor of #10511