Add the ability for plugins to opt-in to asyncronous state calls

[russellmcc]

This adds a new function on state-context that allows the plugin to opt in to receiving save and load calls on a new "state-thread" symbolic thread. Hosts could use this to parallelize loading and saving session state, which can greatly reduce the time it takes to load or save a large session.

This came out of discussion on #255, and is opened as a PR in the hopes that looking at a concrete change proposal is more productive than discussing in the abstract. I'm happy to reject this and continue the discussion somewhere else if that's more appropriate.

Currently left unaddressed is the idea of activating also on a background thread, raised in this comment. I could use ideas on how to allow this. Perhaps state-thread is not a good idea and it should be called bg-thread or something like that?

[abique]

I will propose a different approach which will cover both loading a state or activating the plugin.

[abique]

Here is my proposal: #343

[defiantnerd]

We still need to extend the enum:

enum clap_plugin_state_context_type {
   // suitable for duplicating a plugin instance
   CLAP_STATE_CONTEXT_FOR_DUPLICATE = 1,

   // suitable for loading a state as a preset
   CLAP_STATE_CONTEXT_FOR_PRESET = 2,
};

with a CLAP_STATE_CONTEXT_FOR_PROJECT constant, except that this would be the default?

Resource allocations during a project load linked with enumerated unique resources (hardware!) can only safely be restored properly when properly signalled.