[2428] Create a requirement derivation from the General View

[kkkk1258999]

PLEASE READ ALL ITEMS AND CHECK ONLY RELEVANT CHECKBOXES BELOW

Auto review

• Have you reviewed this PR? Please do a first quick review, It is very useful to detect typos and missing copyrights, check comments, check your code... The reviewer will thank you for that :)

Project management

• Has the pull request been added to the relevant milestone?
• Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
• Have the relevant issues been added to the pull request?
• Have the relevant labels been added to the issues? (area:, type:)
• Have the relevant issues been added to the same project milestone as the pull request?

Changelog and release notes

• Has the CHANGELOG.adoc + doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc been updated to reference the relevant issues?
• Have the relevant API breaks been described in the CHANGELOG.adoc?
• Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
• In case of a change with a visual impact, are there any screenshots in the doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc?
• In case of a key change, has the change been added to Key highlights section in doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc?

Documentation

• Have you included an update of the documentation in your pull request? Please ask yourself if an update (installation manual, user manual, developer manual...) is needed and add one accordingly.

Tests

• Is the code properly tested? Any pull request (fix, enhancement or new feature) should come with a test (or several). It could be unit tests, integration tests or cypress tests depending on the context. Only doc and releng pull request do not need for tests.

---

The unchecked boxes of the Project management section are the ones I have no
permission for: the milestone, on this pull request and on the issue, and the
labels on the pull request. Could someone from the team set them? The remaining
unchecked boxes do not apply: there is no API break and no dependency change.

Fixes #2428

What it does

Adds the New Derived Requirement edge tool on RequirementUsage graphical
nodes, creating a requirement derivation towards another RequirementUsage.
The edge is drawn from the derived requirement to the original one, the
direction the derivation is read in and the direction its edge is displayed in
since #2397.

Implementation

Unlike satisfy, frame, assume and require, which all have a dedicated
metaclass and are created with a plain SysmlFactory call, a derivation is
identified by metadata coming from the RequirementDerivation standard
library. Following your answer on the issue:

• the three definitions are resolved with
  UtilService#findByNameAndTypeInStandardLibraries, the way the standard
  start and done actions already are;
• the import of the library is added to the owning namespace when it is
  missing, through the existing ImportService#handleImport.

The connection and its ends are created by the existing
createConnectionUsage, owned by the namespace owning the source requirement,
so what is added here is only what is specific to a derivation: the
#derivation metadata on the connection, and the #original and #derive
metadata on its ends.

The generated name of the connection is dropped, the way the generated name of
a connector end already is, since a derivation is not referenced by its name.
It keeps a derivation created from the diagram anonymous, as it is when written
in text.

Annotating the ends rather than relying on their declaration order keeps the
direction explicit, which is what the display side uses to orient the edge. The
ends are nevertheless created original first, so that the end order fallback of
the display orients the edge the same way even if the metadata were lost.

The created derivation has the same shape as one written in text, so both can
be mixed in a model, and exporting it gives back a #derivation connection,
which #2419 made possible.

Tests

MetamodelMutationElementServiceTest (unit):

• a created derivation is anonymous, owned by the given namespace, carries the
  derivation metadata and has two resolved ends;
• its ends are annotated, and reading them back with
  getDerivationOriginalEnd / getDerivationDerivedEnd gives the requirements
  passed at creation;
• applying a prefix metadata without a definition applies nothing.

GVRequirementDerivationCreationTests (integration): using the tool between
two requirements displayed in a General View creates the «derive» edge from
the derived requirement to the original one, and the resulting semantic model
has the #derivation connection, its two annotated ends referencing the right
requirements, and the RequirementDerivation import. The model used by that
test deliberately does not import the library, so that the import added by the
tool is actually covered.

GVRequirementDerivationEdgeTests, the display tests added by #2397, still
pass, as do the 212 unit tests of the five modules touched here.

The release notes show the new tool in the edge tool list that appears when
drawing an edge from a requirement, since this is where an edge tool shows up
rather than in the click palette.