Expose the hasher algorithm and type aliases for `HashMap`, `HashSet` and `BuildHasher`

[hcpl]

As I understand the purpose of this crate, the only thing that is different from std::collections::Hash{Map, Set} and other hash-based data structures from other crates is a different hasher. If that is not true, then what I'm saying below is unapplicable, so feel free to close.

The goal is to eliminate the need to maintain a separate Hash{Map, Set} and also reuse impls for Hash{Map, Set} defined in other crates (provided that they are generic over the hasher) so that we don't have to provide them either.

For example, that's how both fxhash and fnv do:

• FxHashMap and FnvHashMap;
• FxHashSet and FnvHashSet;
• FxBuildHasher and FnvBuildHasher.

This is technically a breaking change since the semantics of hashbrown::HashMap and hashbrown::HashSet might be altered in some ways (that I don't know of, unfortunately).

Solving this issue will help solving https://github.com/Amanieu/hashbrown/issues/6 as well.

[Amanieu]

Actually hashbrown is a re-implementation of the underlying hash table based on Google's SwissTable design. It uses FxHash as the default hasher.

[hcpl]

Oh, so I got it backwards. How about generalizing hashbrown for different hashers then? I'm blind and dumb --- it already does it.

Also it might be useful to change the docs a little bit, because "Drop-in replacement for the standard library HashMap and HashSet types" made me think of "a new hasher for standard HashMap and HashSet", not "new HashMap and HashSet implementations altogether".

[Amanieu]

You can use different hashers the same way you do with the standard HashMap: just change the S generic parameter to a different BuildHasher.