update rate management potential improvements

as a follow-up of #146 - for future versions of i-score:

I don't think it's useful or desirable to have same update rates for all automations: sometimes some automations need to be very precise, sometimes they need to be very loose... most of the time, though (at least in my opinion) they don't need to be as quickly updating as they currently do (as of 1.0).

This update rate is depending on each automation purpose... so ideally, the update rate should be defined for each automation (also maybe for other processes ? I don't know..)
Though most of the the time, I think the update rate depends on the destination parameter (and all automations for this parameter might use the same update rate...)

So, my opinion to improve this would be:

• to have a default update rate for all automations (let's say 10 or 15 ms-
• to be able to change this rate for each automation (in the inspector)
• to be able to set a default, or preferred update rate in the device explorer tree for each parameter (so that, by default, every automation created for this parameter would happen at the chosen rate... and could also be changed when desired)
  Does that make sense ?

Of course, this is not a feature request I'm asking to ask upon urgently... I'm mostly raising this here in order for it to be discussed... and hopefully included in a future version of i-score...

On the implementation side (we've been discussing this with Théo this morning), it seems that the clock lays at the constraint level, so one option to handle this would be to keep the constraint clock at the highest possible level (i.e. 1ms for now... and maybe audio vectorsize if handling audio inside i-score ???), and subdivide the constraint clock for each automation, depending on the desired update rate...

I hope I didn't misunderstand things... please correct me (but not too hard !) if I did, Théo...

No files or tests are named. Start by tracing the constraint-level clock and how automation rates are represented, then examine the automation inspector and device explorer parameter flow; done would mean agreeing on and implementing a clear per-automation or per-parameter rate model with a default.