[Core] Improve UX when defining template of a Component

[alxbilger]

To get rid of the template keyword when defining a Component. Example:

<Node name="root">
    <RequiredPlugin pluginName="Sofa.Component.StateContainer"/>
    <RequiredPlugin pluginName='Sofa.Component.LinearSolver.Direct'/>

    <MechanicalObject dofType="Vec2d"/>
    <SparseLDLSolver matrixType="CompressedRowSparseMatrixMat3x3d"/>
</Node>

---

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).

[damienmarchal]

Hello,

+1 for proposing a path to remove the "template" keyword.
But I have the impression you are considering to add aliases. In the past, aliases caused a huge amount of trouble, because people have to discover them and when looking at scene must "know" by heart the aliases to understand the scenes. Having a single name is much better as it ease learning and discoverability.

[alxbilger]

@damienmarchal
It's also something that bothered me. That's also why this PR is only a draft.

I see only two options:

1. We use a unique keyword for the template parameters. It's the case right now, but the term template is not enough descriptive. I doubt we can find another keyword that would suit all the components, but I am open to discussion (dataType?)
2. We define another interface where the template keyword would be here just for compatibility. It could be the case in this PR. In that case, the term alias would not be appropriate. We could trigger a warning if the attribute template is used.

Actually, more generally, this PR defines the template parameters as an associative container key-value. And you are right, the user must know the key. But it is also the case for the Data. We found "solutions" for that: documentation (including the examples) and auto-completion.

[bakpaul]

Third option : We propose a "DataTypeParameters" component, holding all of such parameter for one node, fixing the parameters for all component in this node. Then because it is a component, the user will know where to look for.