[1109] Add support for importing published libraries

[flatombe]

Users may now import a previously-published library into their SysML projects. Importing is done by reference or by copy.

• Backend

  • Add omnibox command to import a published library.
  • Add SysONResourceService with method isImported(Resource) that provides checks for either the specific 'imported' EAnnotation in the root elements, or the presence of a 'LibraryMetadataAdapter' that indicates that the resource comes from an imported-by-reference library.
  • Refactored all calls to ElementUtil.isImported to SysONResourceService.isImported, this way imported-by-reference libraries play well with existing SysON features (Explorer view, read-only mode, etc.)

• Frontend

  • Contribute to the omnibox of the SysON application the Sirius Web generic command to import a published library.
  • Add merge strategy for extension point
    omniboxCommandOverrideContributionExtensionPoint in order to ease composability for downstream applications.

• Tests

  • Tweak integration tests database dumping script to include new Sirius Web tables 'public.semantic_data_dependency' and 'public.library' when dumping.
  • Add integration tests database file that consists of:
    • Project "MyLibrary" used to publish a library with two different versions "v1" and "v2"
    • An empty project
    • An empty project with a dependency to library "MyLibrary" v1.
    • Add integration tests for library import-by-copy and import-by-reference.

• Documentation

  • Add documentation section for importing published libraries in the SysON user manual.
  • Update release notes
  • Update changelog

• Misc

  • Tweak JDT preference
    org.eclipse.jdt.core.formatter.continuation_indentation_for_array_initializer to fit Checkstyle expectations

Bug: #1109

PLEASE READ ALL ITEMS AND CHECK ONLY RELEVANT CHECKBOXES BELOW

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 + doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.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?
• Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc + 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.

[AxelRICHARD]

The code coverage level for syson-application-configuration is also not reached anymore (see the build result). Please add some tests.

[AxelRICHARD]

I will handle the comments myself, rebase and merge the PR.
Thank you!