Factor out assumption of `std::string` for IDs

[weefuzzy]

Whilst our client types work with the assumption of a string type for IDs in datasets, this shouldn't really apply to algorithms: users of a future Freestanding API could very legitimately want to use something else as an ID type (an int, or a pointer, for instance). I think KDTree is the prime culprit here, but needs review.

More generally, we should satisfy ourselves that std::strings aren't being used (or at least created) anywhere that's meant to be real-time safe, as they could heap-allocate. Simply switching over to our allocator-aware basic_string alias isn't completely pain-free because of interactions with the JSON serialization.