Initialisation and cleanup routines for plugin libraries

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](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices#general-best-practices) 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.

Start by tracing how plugin libraries currently expose lmms_plugin_main and their plugin descriptor, then identify the code that handles library loading and unloading. Done means the design for optional lmms_plugin_init and lmms_plugin_deinit hooks is agreed and their lifecycle behavior is covered by appropriate tests or validation.

Written by the indexing model from the issue text.