Allow users to choose between Pipewire and Pulseaudio

The decision to move to Pipewire has already been reached, but has been slow to be implemented due to various issues. I proposed on Matrix to have a way for a user to select between pipewire-pulse and pulseaudio as the main audio stack during pmbootstrap init, similar to how the choice between wpa_supplicant and iwd is presented. This led to @craftyguy agreeing with this idea and improving upon it.

Proposed changes are:

• Decouple audio stacks from UI packages by creating a postmarketos-base-ui-audio subpackage.
  • Currently UI packages dictate the audio stack to be installed. SXMO prefers Pipewire while Phosh hardcodes Pulseaudio.
• Allow UI packages to instead suggest audio stacks to install as default, this showing up as the default option for audio in pmbootstrap as wpa_supplicant shows up as the default networking stack.
  • The user should be able to override this by selecting the non-default audio stack.
• Allow users to select audio stack during pmbootstrap init.
  • pmb_select will prompt the user to choose between Pipewire and Pulseaudio.
  • This could be chosen to be implemented only on edge since it would be a breaking change.

Challenges

• pmbootstrap's pmb_select mechanism will have to be changed to allow for UI packages to determine the default audio stack to be installed.
• Some UI packages strongly prefer one audio stack to another, so we would need to determine how to handle that.
• Adding this to a stable release would be a horrible idea since it would expose a huge amount of bugs to casual users. Maybe only allow choosing the audio stack on edge?

Reasoning

By allowing for users to easily select an audio stack that is not fully supported by their chosen UI or device, they will encounter many issues. These issues can be reported in pmaports or upstream to be fixed, that way there will be less surprise bugs when support is actually enabled.

Also, more eyes will be on the issues, increasing the amount of potential contributors and testing both in our infrastructure and in the upstream UIs to make this shift happen.