Generalize SpanningTree and graph-related methods

[MischaPanch]

Currently we support graph-related stuff only for geospatial data. If ever needed in a more general context (e.g. for arbitrary Euclidean or even non-Euclidean data, arbitrary triangulations a.s.o.), the classes there should be refactored and extended. Here a snippet of a conversation highlighting some of the problems with the current structure:

---

It is related to coordinates, since a Delaunay triangulation only makes sense for euclidean points. If we would like to have stuff only related to the graph representation, it shouldn't be tightly coupled to a special type of graph (representing a Delaunay triangulation). The class

class SpanningTree:
    """
    Wrapper around a tree-finding algorithm that will be applied on the Delaunay graph of the datapoints
    """
    def __init__(self, datapoints: np.ndarray, tree_finder: Callable[[nx.Graph], nx.Graph] = nx.minimum_spanning_tree):

should not depend on an np.ndarray, which has to be an array of euclidean coordinates, since a Delaunay triangualation is computed, but rather a nx.Graph. Moreover, paramter tree_finder allows to construct a subgraph, which may not be a spanning tree at all. Actually, the class only provides convenience methods for inspecting a weighted (nx) graph. So, either the class should be

class WeightedGraphWrapper:
    """
    Wrapper around a nx.Graph
    """
    def __init__(self, graph: nx.Graph):

Or, if you really would like to have a spanning tree, it may look like

class SpanningTree:
    def __init__(self, graph: nx.Graph, mode="min"):
        self.tree = nx.minimum_spanning_tree if mode== "min" else ...

(resp. including an enum for min max). In any case, I don't know if this is enough functionality, to justify a class.
By now, it is tightly coupled to euclidean point graphs (even more, Delaunay graphs), so I would put it into geoanalytics. What do you think?

Originally posted by @schroedk in #50 (comment)

[opcode81]

The class SpanningTree doesn't do a whole lot and what it does is unlikely to be a useful abstraction in general. YAGNI, I daresay. I therefore propose that it be merged with its subclass. Generalising it would, accordingly, not be a good idea in my opinion. (Why was this class created in the first place?)
We could think about moving the Delaunay graph function outside of the geoanalytics package if it is ever needed in another context, but this really isn't a TODO item that should be tracked. I thus propose to close this issue.

[opcode81]

Closing this issue as there was no objection.