New Constructor API

[CorvusPrudens]

This PR introduces a new constructor API:

pub trait AudioNodeConstructor {
    type Configuration: Default;

    fn info(&self, configuration: &Self::Configuration) -> AudioNodeInfo;

    fn processor(
        &self,
        configuration: &Self::Configuration,
        stream_info: &StreamInfo,
    ) -> impl AudioNodeProcessor;
}

This aims to reduce boilerplate involved in node authoring and integration with bevy_ecs. With a node's configuration exposed as an associated type, we can remove the need to create intermediate Constructor types, and we can use this associated type to make concise ECS APIs.

As a part of these changes, I've tried to consolidate some types to simplify their APIs. Most notably, I consolidated the SamplerParams and SamplerHandle types. The RmsParams in the custom_nodes example illustrates why this is useful in a more self-contained way than the sampler.

Not all nodes are completely ported to this paradigm. In particular, the input and output stream nodes as well as the CPAL input node present some issues and may need more consideration before merging.

[CorvusPrudens]

The stream reader and writer have been made Sync and Clone, so they fit better with the constructor design. It would be nice if they could be organized such that the stream configuration is passed in during node construction (instead of the handle's new method), but that may be intractable.

About half of the current nodes have no configuration (so they simply supply the EmptyConfig type as the Configuration). With that in mind, it's possible this approach is not an optimal abstraction. One alternative would be providing two audio node constructor traits: one that takes a configuration and one that doesn't. Of course, two traits isn't perfect either; new users may be confused that some nodes seem to need a configuration when added to the graph while others don't.

Either way, let me know how you're feeling about it!

[BillyDM]

Thanks!

We can worry about how best to structure the stream reader and writer node later. Right now I'm more concerned with stabilizing the audio node API.

As for nodes with no configuration, it's really only nodes which don't have any parameters that have no configuration tied to them. The majority of nodes going forward will have parameters, and thus they will at least have a configuration for the parameter smoothing.