Audio graph modules

This would be essentially like a plugin format, usable through a runtime interface possibly from another dynlib => serialization needed.

Requirements:
- simplified graph instantiation and inspectability. In the future should be able to "see" between nodes
- take an `AudioContext` at creation which contains sampleRate, maxFrame, inverse sampleRate, etc. and gives back a latency. Blocked by #250
- delay compensation looks necessary (aka latency reporting)
- initialization and clearing state should probably be separate, "clearing" not that easy to define (for example, if you enable back an IIR filter you would necessarily have clicks). Maybe ability to run change concurrently? Or perhaps ability to enable to some value but this only avoid 0th-order discontinuity.
- ability to create modules that get to know their channel count at runtime. Eventually aux input like AAX? Need bus description, any number of buses.
- "bypass" process should be a given flag or call
- ability to be "hosted", because audio nodes are akin to an audio plug-in the transition should be smooth. It appears plug-in developer who invest in infrastructure all have some kind of such nodes.
- there doesn't seem to be much need for changing graph between plays, but there is need for disabling/enabling part of the graph dynamically (bypass). Solution for clicks?
- it's useful that AudioBuffer can be attributed with a latency hint, in samples. Basically, this allow to discover latency later and just set metadata in a process, then a special process can realign them, and reinitialize its delayline only if changed. Needs dynamic latency to be useful.

Start by reading this issue alongside the blocking issue #250, which concerns the AudioContext requirement. The issue lists possible graph-module capabilities but leaves key design questions unresolved; a concrete definition of scope and acceptance criteria would be needed before work could be considered done.

Written by the indexing model from the issue text.