Update `unique_trie` to compare against native Rust `HashMap` module

[matthewhammer]

Currently, we are comparing against other ways of folding over the tree (representing a sequence) to build a list (not a set), and a sorted, de-duplicated vector (which is somewhat set-like, in that it only contains each key at most once).

However, as we know, these comparisons aren't entirely "fair":

• The version that builds a list isn't a "fair" comparison, since the list has duplicates, is unsorted, and does not permit an efficient membership test for elements.
• On input data with many distinct keys (e.g., 64-bit uniformly random numbers), the version that builds a vector is so slow compared to the Trie- and List-building versions that it's not even interesting. (On inputs with very few distinct keys, it's quite fast, however).

An interesting future comparison line would consist of the following:

• Its input is a random (native Rust) vector, which is mutated randomly,
• Its computation consists of folding over its elements to produce a (native Rust) hashmap.

If we can beat this non-incremental, from-scratch computation of native Rust code with our incremental Trie, then we have a compelling story to tell.

[kyleheadley]

I removed the incremental vec version that was sorting and deduping its elements, and added a non-incremental hash map version (the incremental version with hash map as accumulator is not trivial because HashMap is not Hash, that is, the full struct is not hashable, so it is incompatible with Adapton)