Re-think design of interface for block parameters

[stephanemagnenat]

Currently, blocks inherit from BlockDefinition. They must provide two components, editor and miniature, that both must provide a params property and a getParams() method. In addition, they must feel the defaultParams property.

This poses several problems:

1. If a block uses a complex object for storing its parameters, such as MusicScore, it is hard to avoid binding to a single instance of this object, leading to a shared object for all instances of the block.
2. Typically, the params properties of both editor and miniature are manually set to defaultParams, which is confusing. And, as a property is set, it prevents the instantiation of an object pragmatically, which would be necessary to avoid the shared object explained in point 1.

We should improve that. The least is to document the interface, in particular when params should be assigned and by whom. Also, maybe having a method of BlockDefinition that returns default parameters would be better than having a property, to allow for dynamically-created objects.

[stephanemagnenat]

Based on my recent experiments, it seems that the cleanest way to implement the current interface is to create a QML file with the actual editor, having a params property and a getParams() method, and in the block QML file, embed these editors in components, and set the params property to defaultParams, itself set to a JSON object describing default parameters.