[LinearSystem] MatrixProjectionMethod: Fix out-of-bounds matrix writes

[fredroy]

MatrixProjectionMethod::addMappedMatrixToGlobalMatrixEigen iterated over the cartesian product of the union of both mechanical states' top-most ancestors, instead of inputs1 x inputs2.
For the resulting spurious pairs no Jacobian exists, and computeProjection silently falls back to an unprojected block whose dimensions belong to the mapped state, written at the global offsets of an unrelated state.

[with-all-tests]

[ci-depends-on https://github.com/sofa-framework/Regression/pull/126]

---

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

---

Reviewers will merge this pull-request only if

• it builds with SUCCESS for all platforms on the CI.
• it does not generate new warnings.
• it does not generate new unit test failures.
• it does not generate new scene test failures.
• it does not break API compatibility.
• it is more than 1 week old (or has fast-merge label).

[fredroy]

for windows....
[ci-build][with-all-tests]

[sofabot]

[ci-depends-on] detected during build #4.

To unlock the merge button, you must

• Merge or close Update regression due to PR6256 (MatrixProjectionMethod fix) Regression#126
  For this build, the following CMake flags will be set
  -DREGRESSION_GIT_REPOSITORY='https://github.com/sofa-framework/Regression'
  -DREGRESSION_GIT_TAG='06148ea71569a494d56a7e1b9e6975a54500065e'

[alxbilger]

Strongly related to #6222

[alxbilger]

I am afraid Claude is wrong!

Consider a spring that has 2 input mapped states resulting into 2 mapping jacobian matrices: $J_1$ and $J_2$. The cartesian product suggested by Claude would lead to the pairs $(J_1, J_2)$, while the previous code would lead to $(J_1,J_1)$, $(J_1,J_2)$, $(J_2,J_1)$, $(J_2,J_2)$. The latter is the correct solution. It would lead to $J_1^T K J_1$, $J_1^T K J_2$, $J_2^T K J_1$, $J_2^T K J_2$, i.e. the totality of the coupling terms.

I suggest to close this PR.