[437097] Case of resizing parent with children that have edges

This commit resolves the scenario of comment 14 [1]. To be more
complete, it handles several cases:
* Edges of border nodes during resizing of parent from west or north
side 
* Edges of border nodes during resizing of parent from east or south
side with centered rezise (CTRL key)
* Edges of children nodes during resizing of parent from west or north
side with "move children" rezise (F3 key)
* Edges of children nodes during resizing of parent from east or south
side with centered and "move children" rezise (CTRL+F3 key)

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=437097#c14

Bug: 437097
Change-Id: Iac7daef3a98bfff5924b41964033a48bfbc1dfe2
Signed-off-by: Laurent Redor <laurent.redor@obeo.fr>
[437097] Cleanup of some methods and variables name

Use "border node" instead of "bordered node"

Bug: 437097
Change-Id: Ia3633ce33837f5adc481b13b199001fe2d0336ae
Signed-off-by: Laurent Redor <laurent.redor@obeo.fr>
[441483] New feature and update-site with all tests dependencies

Add a new feature named oes.tests and a new update-site
oes.sirius.tests.update, which for now contains only the sample
metamodels and modelers which are needed by the automated tests, but not
the tests themselves (they will be added in a later step).

Because some of the tests and test modelers depend on "Sirius Query
Legacy" which itself depend on Sirius, the new feature and update-site
must be built in a separate step, using augmented Target Platforms which
include both Sirius and Sirius Query Legacy. See the
releng/oes.targets/sirius_tests*.* files.

By default, these new Tests Target Platform get their version of Sirius
from the latest nightly. To get a full consistent build using a Sirius
core built using the exact same sources as the tests themselves, the
location where Sirius is obtained can be overridden using a Maven
settings file. This requires to jump through some hoops because Maven
settings require absolute paths, which we can not predict. The new
script build-all.sh at the root shows how this can be done.

The new update-site/repository is published in a sub-directory of the
main one, but the shortcut URLs (e.g. updates/nightly/latest/luna)
aggregate boths, so downstream consumers do not have to be aware of the
physical split.

Bug: 441483
Change-Id: I06edf372223c43026bbea2256680858d134b67a6
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
[444569] Initialize the feature specification

Bug: 444569
Change-Id: I554a5b8fef6e7dbb0c3fe367137023b098842abc
Signed-off-by: Florian Barbin <florian.barbin@obeo.fr>
[437528] Since bug 441424, the centering style of edges is not respected

If the centering style is "enabled" for an edge, this overrides the fact
that the edge keeps its location.
This commit fix the problem of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437528#c12

Bug: 437528
Bug: 441424
Change-Id: Icdef14b9c698f5865569baefc8726a0edba9abf1
Signed-off-by: Laurent Redor <laurent.redor@obeo.fr>
[443108] Display the menu action only for Connections

* Restrict the action visibility to Sirius Diagrams.

Bug: 443108
Change-Id: I52811925b6c0452f2faaf3473737f1f6a07a1023
Signed-off-by: Florian Barbin <florian.barbin@obeo.fr>
[437097] Case of d'n'd of border node in container with scrollbar

* For drag'n'drop of border nodes, the location of the feedback is
stored in the request (see
SpecificBorderItemSelectionEditPolicy.showChangeBoundsFeedback).
* This location is used just after in SiriusContainerDropPolicy to have
the real location for each dropped border node.
* The adaptation made in ConnectionsFactory for border nodes is now
unuseful because the real location is directly used in
SiriusContainerDropPolicy.getSaveLayoutCommand().

Bug: 437097
Change-Id: I1d7eb2b93aeb874f8ba5de6547d3640ebf390918
Signed-off-by: Laurent Redor <laurent.redor@obeo.fr>
Session.save will now postpone the save in post-commit
Activate IsModifiedSavingPolicy by default
Improve IsModifiedSavingPolicy to avoid False Positives

This adaptation of IsModifiedSavingPolicy is closer to the
SavingPolicyImpl strategy:
1. it uses the resource.isModified state as a basis to compute
what needs to be saved. Any resource marked has having been migrated
will also be considered "logically modified".
2. it browse the other resources to detect dependencies toward
resources which are modified
3. it filter this set of logically modified resources by serializing
them in a file buffer and comparing the result with the current file.

This strategy has the following characteristics :
- we avoid many serializations compared to the SavingPolicyImpl
  implementation by using the isModified boolean
- On the other hand we might browse the models, but this is made in a
  way that proxies should not be resolved. In practice this did not even
  came up in the profiling traces.
- we will never ever actually save the file if there is no change (just
  like the previous policy)
- If we *miss* a resource in the first step and don't consider it
logically modified whereas we should, its a bug and some resources might
not have been saved.

Also this commit makes sure only platform:/resources are considered
(which is important for CDOResources for instance, we don't need to
browse the model there, or Ecore resource with http:// URIs, we don't
need to send PUT on the Eclipse Server...)
It make sures non existing files will be saved anyway as their
"isModifed" status would not be enough for a resource which just got
created in memory for instance.
It also makes the IsModifiedSavingPolicy ignore resource.isLoaded
when deciding whether a resource has changes or not. This is necessary
to keep the same behavior as the reference policy.
Introduce a ResourceMigrationMarker

This marker might be attached to a Resource to indicate that
some automatic migration *might* have change the structure
of the model during the loading (with no isModified flag)

This forces the IsModifiedSavingPolicy to consider this resource as
"logically modified".

This marker is automatically removed when the resource is processed
by the saving policy which checked that the serialization has no
difference with the current file content.