Allow Pedalboard instances to be used as plugins.

[psobot]

Oh boy, this is a big one. This PR:

• Adds the concept of a PluginContainer on the C++ side to represent a plugin that internally delegates to zero or more Plugin instances.
• Adds two subclasses of PluginContainer:
  • Mix, which mixes the outputs of multiple Plugin instances in parallel
  • Chain, which runs plugins in series (as the Pedalboard class does now)
• Makes the Pedalboard class a subclass of Chain, allowing it to be used as a plugin itself
• Adds new examples to the README
• Removes the sample_rate parameter from Pedalboard instances, which may be a breaking API change for some users
• Changes the Python interface to use std::shared_ptr under the hood (to allow for better alignment with Python's reference counting)

[drubinstein]

So the use of shared_ptr here may turn into a performance penalty since shared_ptrs come with thread locks. If you can pass around Plugin& and initialize from your PluginRegistry, you may have a better time (pun intended)

[psobot]

That'd definitely remove the need for a shared_ptr here, but we don't actually have a PluginRegistry or similar - plugins' lifetimes are managed in Python, and the switch to shared_ptr here was in order to bridge more cleanly with Python's reference counting semantics.

My understanding is that shared_ptr only uses a lock when changing the reference count, though; and in our case, that should only ever happen in three places:

• in the constructor of each plugin (implicitly via pybind11 when returning from py::init)
• in Python (when objects fall out of scope)
• when modifying the list of plugins in a PluginContainer (which should only be triggered by a Python operation to begin with)

We do release the GIL to allow for multithreaded processing when actually rendering audio, but at that point, we're not going to trigger any of the three situations above; hence this shouldn't cause any locks to get hit, and we should end up with no performance penalty.