[staging] ♻️ Improve specification of clp_constraints

[jsnel]

One of the current pain points is related to specifying clp_constraints (type zero) where you are somewhat left 'guessing' the internals to know what target to write.

For instance, at the end of the model specification, 200 lines down from where the complex/element is fist specified you may find a clp_constraint tht looks like this:

clp_constraints:
  - type: zero
    target: coherent_artifact_1_artifact
    interval:
      - [1100, 1900]

Here coherent_artifact_1_artifact is not explicitly defined anywhere, you just need to 'know' it exists, because you have a coherent artifact, with at least order 1, named artifact. 🙈 Even worse are the mixin of pfid and damped-oscillation related oscillation components. Needing to name the oscillation of doas dosc1, docs2, etc

SO that in zero constraints you can figure out that

 - type: zero
   target: osc2_sin
   interval:
   - [1450, 2000]

is related to PFID, whereas

 - type: zero
   target: dosc2_sin
   interval:
   - [1450, 2000]

is a zero constraint related to doas.

I think we could take advantage of the fact that the new library/elements definition could allow for easier close to the source definitions.

Proposed refactoring

• make clp_constraints part of elements (close to target)
• each elements get unique clp_constraints
  • bubbling up (implicit constraints) was discussed to be undesirable, so explicit it is
  • some excessive copy pasting could be avoid by clever use of yaml syntax
• as part of implementation investigate possibility for extend mechanism to preserve (keep) constraints
• (new) target can be one or more compartments, with None implicitly meaning all components in the element

Benefits

• Specification of constraints (much) closer to their target (less ambiguity)
• Simpler model specifcation, less error prone

Possible cons

• Change w.r.t. 0.7.x API (lots of changes already anyways)
• Specification of element more complex (but only a little bit)

Additional context

It should be investigated if the other constraints (equality, equal area) could benefit from a similar refactor.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.