[WIP] Reduce time spent in eval and der in equation resolution

[vidaldid-rte]

This PR implements the idea of #778 (that is minimizing memory cache misses during equation eval and der) in a way that is compatible with the current equation model and that keeps its properties (code isolation, lazy evaluation when done outside of NR, object model).

Results

Computation time divided by 1.8

Der and eval are no longer the top hotspot in a Security Analysis

Before:

With the PR:

Implementation

A VectorEngine is in charge of computing eval and der used in the NR resolution.
The optimization is performed on branch equations.
To minimize cache misses, the terms are sorted element type, element num (which is most often a branch), equation element num (wich is most often a bus), then by bus, then by variable (for der operations).
Branch data is stored in a unique array ordered by branch num.
To avoid loading small objects (like terms and equations), their active status and equation columns are replicated via the notification system in an ordered array.
Some terms provide static interfaces called VecToVal that enable to compute derivatives or evalLhs without loading the term object. This is done at this time for close branch equations on P and Q.
Branch typical values (sinksi, costhetha1, costheta2 etc..) are computed only once per branch.

Known issues

• Probably remaining memory cach miss due to the network structure (hard to visit at the same time branch and bus in the data roder)
• Two tests currently deactivated. Need investigation and resolution.
  Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.1% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud