Make Sound servers Hardware objects

[sneakers-the-rat]

Working on refactoring prefs and configuration right now, and part of that is remaking the way that HARDWARE prefs are done. I think it makes sense to start considering the audio server as a hardware object since that would unify configuration, make the need for flexibility of backend and soundcard more explicit, and reduce the number of separate streams of objects to maintain. We also could link up with https://github.com/wehr-lab/autopilot/issues/158 and generalize the nascent calibration property of Hardware objects.

In order to also reduce the coupling between objects, I think rather than using a singleton class and a bunch of global variables we could have some backend option to sound classes, split up methods, and use decorators to override, eg, init_sound methods according to different backends. for example

from typing import Optional, TYPE_CHECKING
from autopilot.hardware.sound import instance

if TYPE_CHECKING:
    import numpy as np

class Tone(Sound):
    def __init__(self, ..., server: Optional[Sound_Server]=None):
        if server is None:
            self.server = instance()

    @backend.jack
    def init_sound(self) -> "np.ndarray":
        ...

    @backend.pyo
    def init_sound(self):
        ...

While we're at it, there's no reason to hold open a persistent sound server using the Pilot, and we could instead do something like how the GPIO class intializes the pigpiod daemon as well as a connection on the fly, as needed. https://github.com/wehr-lab/autopilot/blob/e408c08e76df8d8c930edfb4ba58e31cd1ec4d87/autopilot/hardware/gpio.py#L201-L213

(btw i'm also working on making audio way easier to configure by basically splitting out configuration to take into consideration hardware objects, better integration with alsa to, eg. autodetect sound cards, long time coming)

Posing this as a question/idea, so disagreement welcome