Make `bevy_audio` agnostic

[harudagondi]

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

• Currently, there are several audio plugins in the bevy ecosystem, like:
  • bevy_audio, uses rodio internally
  • bevy_kira_audio, uses kira internally
  • bevy_oddio, uses oddio internally
  • There's also bevy_synthizer, developed by Nolan#4103 on the bevy discord
• Making bevy plugins for audio stuff is hard, see here, and PR for bevy_fundsp here: harudagondi/bevy_fundsp#6
• Like how wgpu have many backends abstracted away, I think bevy_audio should do the same.

What solution would you like?

• Majority of the types in bevy_audio should be converted into traits

  • Audio will be a trait that supports playing audio with the given settings
  • AudioSource will be a trait that holds static data, and have a new or init static method
  • AudioSink is a trait that has basic methods for playing or pausing audio (plus some other niceties like in bevyengine/bevy#5828)
  • AudioPlugin should hold its own backend, like what I did in bevy_fundsp

• A default backend for rodio, implemented in bevy_audio, or a separate bevy_rodio crate

• Bevy audio plugins that are just backends implement the traits in bevy_audio and should just work

I don't really know what the exact implementation would look like, but I do know it probably would have a bunch of trait magic and generics, sooo

What alternative(s) have you considered?

• Do not do this. Just let third party audio plugins replace bevy_audio outright.
  • As mentioned before, this will make the creation of third party audio plugins that isn't replacing bevy_audio very boilerplatey and kinda hard, as you'll have to make your code work on every audio plugin, and each plugin is very different.
• Do not remove the original types, but create several traits as mentioned above, and make rodio the default in bevy_audio
  • using third party audio plugins will have both rodio, and kira for example, compiled in the same crate, which is not ideal, especially if rodio will not be used in the first place

Additional context

• I'm working on harudagondi/bevy_fundsp#6
• Making your own Backend trait to support different plugins is kinda frustrating
• UPDATE (2022/11/12): I have written a pre-RFC for this, and I'm currently prototyping a new library.