Hash a vector to a scalar

There is an existing issue #1031 that mentions that hashing a vector input to a scalar as a desirable output. While we can expand the set of types supported by hashing immediately (as done in #1303), the problem of how to hash vectors to a scalar is surprisingly thorny.

The fundamental root of all difficulties lies in the idea that a sparse vector must be considered logically equivalent to a dense vector of the same length. So: the length 4 sparse vector `{1:"hello", 3:"friend"}` should hash to the same value as the dense vector `{"", "hello", "", "friend"}`. Yet it should not hash to the same value as `{"hello", "", "", "friend"}`, or `{"", "hello", "", "friend", ""}`, or some other such inputs.

Beyond handling of how to handle sparse vectors and dense vectors with default values, there is also the problem of how to handle the "not ordered" option. The primary reason the not ordered option is valuable is because we want to use the hash transform in place of a dictionary-based term transform, to enable a bag of words representation. Yet if the ability to map both `{"a", "b", "a"}` and `{"a", "a", "b"}` to the same output vector (in the case of bag-of-words) is valuable, would mapping both to the same hash also likewise be a valuable property? If we *don't* believe this is valuable, what does being unordered in the case of a single hash actually mean? Nothing? Should it be disallowed, ignored?

No files, tests, or entry points are named. Start by reviewing the related issues #1031 and #1303 and the existing hash transform behavior. Done requires resolving sparse-versus-dense equivalence and defining the meaning of the unordered option before implementation.

Written by the indexing model from the issue text.