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

In certain contexts, it is advantageous to store temporary assets in the underlying filesystem which may or may not be deleted when the application exits.

What solution would you like?

• A new AssetSource, bikeshedded as temp:://, which will use an appropriate system folder to store assets written to it during runtime.
  • This may be appropriate to expose as a configuration option.
  • Note that the tempfile crate is currently transiently included in Bevy, so an implementation based on it should have no impact on build times.
• The source may or may not be empty on application start (cached assets from a previous run for example). It should be configurable as to whether the temp:// source will be explicitly cleared on startup.
• The source may or may not be cleared on application exit (cached assets for a future run for example). It should be configurable as to whether the temp:// source will be explicitly cleared on exit.

What alternative(s) have you considered?

Temporary assets can currently be stored in-memory, and thus automatically "deleted" on program exit.

Additional context

A bit tangential, but this would be an awfully similar arrangement to offering temporary files as an asset source (temp:://). Perhaps a proof of concept for the asset source component of the preferences API could be experimented with there?

Yeah a bit tangential. I don't think the Asset Sources feature needs proving out as its already in use, but I do think a temp:// asset source would be useful. Worth implementing!

Originally posted by @cart in #13312 (comment)