ECL: use a Guava Network for MatchTrace

[agarciadom]

This pull request replaces the recent optimisation of the MatchTrace in ECL with a Guava Network (a directed multigraph, configured to allows parallel edges between the same pair of nodes and self-loops).

In this graph, a match from a to b is represented as an edge from a to b, and is associated with its Match object.

This pull request shortens MatchTrace by about 174 lines, and in my opinion leaves it in a more readable state. There are some caveats, though:

• Guava MutableNetworks do not offer any thread-safety guarantees, so we have to manually synchronise on them when concurrent = true. I've implemented a syncOn function that does that.
• While the total set of edges is ordered by insertion in the Network, the various views coming from it (e.g. in/out edges of a given object) are not. I had to implement a map that keeps track of insertion order for matches myself. This is a known issue in Guava Networks.
• The various views of a Guava Network (e.g. the .edges() and .nodes()) views cannot be modified, so the iterator() produced by MatchTrace does not support modification anymore.

The good news is that this seems to have pretty much kept (or perhaps slightly improved) the performance of the IncrFWD scenario in the reference implementation of the TTC 2023 Containers to MiniYAML case, compared to the one from the Map-based structure:

------------------
Incr. FWD:
------------------
n_containers,n_volumes,n_images,Epsilon
50,3,4,4.977

[agarciadom]

Note: this passes all tests from Eclipse (including plug-in tests). There is an ongoing Jenkins CI build for this: https://ci.eclipse.org/epsilon/job/interim-kubernetes/job/guava-matchtrace/1/

[agarciadom]

All tests passed on Jenkins.