Refactor versionable extensions versions

[flo-dup]

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)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?
No

What kind of change does this PR introduce?
Design fix

What is the current behavior?
Many parameters relative to each serialization version are defined separately

What is the new behavior (if this is a feature change)?
Each version is defined with all the parameters relative to it

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)
Starting from this release, AbstractVersionableNetworkExtensionSerDe constructor now takes only 3 arguments:

• An extensionName, like before
• An extensionClass, like before
• An array of versions (objects extending SerDeVersion), which replaces
  • the namespace default prefix
  • the namespace URIs
  • the resource path to the xsd
  • the extension versions corresponding to an IIDM version
  • the list of AlternativeSerializationData describing the alternative serialization names
    (more details to come once concept is validated)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud