Refactor default library

[Lisrte]

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?

No

What kind of change does this PR introduce?

Dynamic model default library used by builders are now explicitly defined in models.json

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:

[flo-dup]

I'm wondering, why did we choose to have default as a parameter of each library? It would be more appropriate to have a defaultLib for each category, it would ensure by design the unicity of the default lib. For instance:

"gridFormingConverters": {
  "defaultLib": "GridFormingConverterDroopControl",
  "libs": [
    {
      "lib": "GridFormingConverterDroopControl",
      "default": true,
      "properties": [
        "Synchronized"
      ]
    },
    {
      "lib": "GridFormingConverterMatchingControl",
      "properties": [
        "Synchronized"
      ]
    },
    {
      "lib": "GridFormingConverterDispatchableVirtualOscillatorControl",
      "properties": [
        "Synchronized"
      ]
    }
  ]
}

What do you think?

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
96.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud