Refactor smr.algorithm.SemanticMatchGraph to deal with multiple metrics

[s-heppner]

Previously, smr.algorithm.SemanticMatchGraph only allowed for one edge between two nodes (as it inherits from nx.DiGraph). This was expected in a sense, because the graph implied semantic model only works with one edge per set of nodes.

However, my concept allows for two nodes be connected by multiple edges, representing semantic similarity scores from different matching methods (e.g. semantic similarity metrics, as I call them). A user would want all of them reported.

To fix this apparent mismatch of requirements, I implemented the following:

• We keep the nx.DiGraph structure as is, as all the other algorithms rely on it, and it only makes sense for the graph implied semantic model.
• The weight of the edge is always the one all the algorithms work with (similarly how the smr_alignment.TriangleViolationChecker writes the "repaired" similarity scores to the weight).
• We store additional similarity scores in a Dict[metric_id: score] called metric_scores (or similar) as an additional attribute of the edge.
• When adding a new score to an existing edge, choose max(metric_scores.values) as new weight, as this minimizes the triangle inequality violation of this metric and this is the one the TriangleViolationChecker would choose always anyway (if we implemented a Dijkstra or Floyd-Warshall that could deal with parallel edges).

This change necessitated a rat's tail of other changes:

• algorithm.SemanticMatchGraph.to_file() now stores the actual graph in the file, not a list of SemanticMatches. algorithm.SemanticMatchGraph.from_file() is adapted accordingly. This is backward incompatible!
• We adapt algorithm.SemanticMatch with two new attributes:
  • metric_id: Globally identifying string of the metric used (e.g. the NLP model + version)
  • graph_score: The score that was considered in the SemanticMatchGraph's search algorithm. This value can be ignored in most cases and is more interesting as a debug information. It might explain why a SemanticMatch with this score was returned by the query, even though the score might not fit.
• We adapt service to deal with the changed data structures
• We adapt the unittests accordingly

Not strictly necessary, but while we were at it, we also changed the get_matches endpoint to query_matches, since GET was wrong from an HTTP specification point of view. We're not getting static data, but performing a computation.

We bump the version of semantic_match_registry to 1.0.0 in the pyproject.toml, not because it is now considered stable, but rather because of semantic versioning and this being a backward incompatible change.

Fixes #10