[SpatialPartitioning] Refactor KdTree into KdTreeDense + KdTreeSparse

[azaleostu]

This PR moves the subsampling API of the kdtree into a separate type (KdTreeSparse). Having two separate types for regular kdtrees and subsampled kdtrees will make it easier to implement inverse sample mapping (i.e. mapping point indices to sample indices) which we need to allow constructing KNN graphs from subsampled kdtrees (see #114).

Changes

• Separate the KdTreeBase class into a KdTreeImplBase class containing common features and two derived KdTreeDenseBase and KdTreeSparseBase classes
• Add utility functions for converting sample indices to their corresponding point index/point data, see pointFromSample and pointDataFromSample

[nmellado]

From a user perspective, the class KdTreeImpl is frequently used to access types and take objects as inputs in functions/methods. In this context, the name KdTreeImpl sounds here a bit weird, KdTreeBase would make more sense.
Maybe we could update the names in the inheritance hierarchy, in order to help users understand the meaning of each class (especially the ones used downstream).

[nmellado]

From a user perspective, the class KdTreeImpl is frequently used to access types and take objects as inputs in functions/methods. In this context, the name KdTreeImpl sounds here a bit weird, KdTreeBase would make more sense. Maybe we could update the names in the inheritance hierarchy, in order to help users understand the meaning of each class (especially the ones used downstream).

@azaleostu did you see this comment ?

[mazestic]

From a user perspective, the class KdTreeImpl is frequently used to access types and take objects as inputs in functions/methods. In this context, the name KdTreeImpl sounds here a bit weird, KdTreeBase would make more sense. Maybe we could update the names in the inheritance hierarchy, in order to help users understand the meaning of each class (especially the ones used downstream).

@azaleostu did you see this comment ?

yes! so renaming the KdTreeImplBase class to KdTreeBase, and renaming the KdTreeImpl typedef to KdTree?

[nmellado]

From a user perspective, the class KdTreeImpl is frequently used to access types and take objects as inputs in functions/methods. In this context, the name KdTreeImpl sounds here a bit weird, KdTreeBase would make more sense. Maybe we could update the names in the inheritance hierarchy, in order to help users understand the meaning of each class (especially the ones used downstream).

@azaleostu did you see this comment ?

yes! so renaming the KdTreeImplBase class to KdTreeBase, and renaming the KdTreeImpl typedef to KdTree?

Seems to be more user friendly, yes. Are you fine with it ?