Previously, preparing an AudioProcessorGraph containing hosted LV2
plugins would recreate the plugins and then set their state. For plugins
without threadsafe restore, setting the state would take the
callbackLock to avoid races with processBlock. This meant that

- During prepare, the graph would take the processorLock, then the
  processor would take its own callbackLock.
- During playback, the graph would take the processor's callbackLock,
  and then would take the node's processorLock.

This is probably benign (prepare shouldn't be called concurrently with
processBlock at all), but to be on the safe side we now avoid taking the
callbackLock when setting new plugin state during prepareToPlay.

MIDI only plugins are no longer provided valid audio buffers
Graph nodes are only executed when they have active connections

Previously it was possible to have a dangling resource map. In that case
opening an AU from a file that did not have a resource map would lead to
using the previously unclosed map and attempting to load the previous
plugin again.

fc378aaf9a introduced a regression where
plugins with no audio channels (such as MIDI FX plugins) would receive
an audio buffer with a length-in-samples of '0', rather than the actual
block length.

These were mistakenly removed in afe5199848

Fixes an issue introduced in 72fa2d98e1
where zeromem might write past the end of the channel buffer.

If the block size changes from block to block, then it's possible for
inputBuffer to be smaller than buffer, but for buffer to be smaller than
the initially-allocated size of inputBuffer.

We haven't updated the default post-build copy paths yet, as the new
local directory is not yet well-supported by DAWs.

When plugins change their 'parameter info' this often means that their
previous parameter text is no longer valid, so we should fetch new text
to represent the parameter value.

This change was primarily tested with Kontakt.