Refactor/split kdtree

[minnerbe]

As discussed in #333, I made some attempt to refactor the implementation of KDTree. In particular:

• Values and positions are now in their own classes (KDTreeValues and KDTreePositions, respectively), thereby also separating storage details of the positions from KDTreeImpl.
• KDTreeData now is only a container providing easy access to data used in serialization.
• Creation logic for values and positions is outsourced in their respective classes, meaning that there are only #(value backends) + #(position backends) constructors instead of the #(value backends) * #(position backends) constructors of KDTreeData before.

The benchmarks with 1M points look very similar to those before the refactoring with slightly worse timings. Some of the difference, however, might be explained by my laptop's current temperature and power settings. Unfortunately, I don't have access to a more stable test hardware to do a proper comparison right now.

KDTreeBenchmark.createKDTree            avgt    8  322.834 ± 23.371  ms/op
KDTreeBenchmark.kNearestNeighborSearch  avgt    8   99.910 ±  6.377  ms/op
KDTreeBenchmark.nearestNeighborSearch   avgt    8   64.412 ±  6.320  ms/op
KDTreeBenchmark.radiusNeighborSearch    avgt    8   66.110 ± 11.759  ms/op

Although there are still a few rough edges, I am quite satisfied with how this turned out. In particular, the other searches work without adaptation and for the serialization experiments only very minor and obvious changes are necessary.

What do you think @tpietzsch ?

[tpietzsch]

I like the split of KDTreePositions into a separate class. KDTreeImpl and the searches only needs that, very neat!

I reverted the split of KDTreeValues. It looked weird to me because it doesn't have much to do with KDTree, it's more "1D RAI like thing", and in the end I just put it back into KDTreeData.

[tpietzsch]

I merged this into #333

[minnerbe]

I agree, splitting KDTreeValues out of KDTreeData did look a bit awkward. Thanks for considering this!