Conservative fixes for Plugin API

[cbjeukendrup]

Resolves problems with the Align property type, which was refactored in libmscore but those changes weren't properly applied in the Plugin API; for now, I've added some logic between the Plugin API and libmscore, so that the Plugin API is working again without differences from MS3 in this regard.

Furthermore, this reverts a change regarding the Plugin API's instrumentId: in MS3 (including 3.6.2), this returned the MusicXML id, and in MS4 it would return MuseScore's own instrument id. I have decided to revert this, so that existing plugins will work properly in MS4.0.1 without any changes.
Alternatively, we could decide that this change is intentional and that plugins will need updating for MS4. Not sure what's better here. @igorkorsukov @shoogle what do you think?

[igorkorsukov]

I would like us to have a stable API that is only expanding (not changing) and/or explicit API versioning. Also, I believe that the best functional API (just like in an autobot https://github.com/musescore/MuseScore/tree/master/src/autobot/internal/api, ), and not an object one, because it is easier to maintain backward compatibility, easier to expand, etc., respectively, in the end this approach will give a more stable and powerful api. But these are all questions of the future (maybe this year).

Accordingly, now we have a situation, on the one hand, we have released a new major version, and we can change the current API (this will not be unexpected), on the other hand, we know that we want to make a completely different API in the future, and therefore if we change the old API, as a result we will get two versions "old API" - this will confuse us all and complicate management.
So, I think the right decision now is to provide backward compatibility for the old API and not change anything in it, so that there are just "old API" and "new API".

[cbjeukendrup]

Also, I believe that the best functional API (just like in an autobot https://github.com/musescore/MuseScore/tree/master/src/autobot/internal/api, ), and not an object one

Some thoughts about this:

• It might be nice expansion of the possibilities if users could also have "hooks", like onScoreOpened, onScoreClosed, onActionTriggered... with the current object based model, this could be easily designed by using signals. In a functional API, we could give users the ability to subscribe to signals explicitly, but maybe it's not as nice, because then the code that manages those subscriptions still needs to be triggered before the plugin works. (But if we can do that automatically, it's not a problem per se.)
  I can imagine it would be nice to have plugins that you enable once, and then they will automatically be subscribed to the various signals every time that MuseScore is opened. (A concrete example I'm thinking of is the "Discord Rich Presence" plugin, which connects MuseScore to Discord to show which score you are working on. Some people are enormously enthusiastic about this thing.)

• In MuseScore 3, it was possible to have plugins that become a dock panel or dialog. This was quite widely used, and very useful in my opinion. We should make sure to keep providing an alternative for this.
  (More generally: I think we should not think of plugins as a simple script where you press "Run", and then it performs some actions, and then it's done. Instead, we should approach them more broadly, as real extensions of the program, that can have their own bits of UI, and can work together with multiple parts of the app.)

[igorkorsukov]

I totally agree with you!
In my previous project, I designed just such a plugin system that provided not only script execution, but also added full-fledged functionality in the form of pages, dialogs, panels... And it could even replace the built-in functionality, for example, it could replace the dialog for creating a new score with another one.

I can imagine it would be nice to have plugins that you enable once, and then they will automatically be subscribed to the various signals every time that MuseScore is opened.

We can call the init function in the plugin script if it present at the start of the application (when modules are initialized), in which we can "initialize" the plugin, for example, subscribe to events.