Initialisation and cleanup routines for plugin libraries

[DomClark]

Some LMMS plugin libraries may need to manage resources that outlive any particular instance of a plugin from that library, initialised either when the library is loaded or upon first use and disposed of when the library is unloaded. The natural approach here would be to handle these using RAII in a static/global object. However, on Windows there are heavy restrictions on what can be done when constructing and destructing static objects. The standard solution to this is to export initialisation/cleanup functions, which are called after the library is loaded and before it is unloaded. I propose to add two new optional functions for plugin libraries to export: lmms_plugin_init for initialisation, and lmms_plugin_deinit for cleanup. (Currently we export lmms_plugin_main for instantiation, along with a descriptor for the plugin).

(The motivation for this is for VST3 support, which I'm currently working on. VST3 plugin libraries typically have longer lifespans than the plugins they contain, so a separate cleanup mechanism is required. However, this may prove useful elsewhere in the future.)

@lukas-w May I have your views on this in particular? I brought this up informally on Discord and nobody said much, but @tresf specifically mentioned asking you.

[lukas-w]

Additional exported initialisation & cleanup functions sounds like a good and clean way to solve this. The only other solution I can think of is to use a reference counter in the plugin's constructor/deconstructor, but this would mean cleanup is run when the plugin's last instance is destroyed, not when the plugin is unloaded (i.e. LMMS quits). Depending on the nature of the resources you manage this may or may not be what you want.