Replace internal hashtable with hashbrown RawTable

[arthurprs]

Replace internal hashtable with hashbrown RawTable.

Benefits

• Allows only hashing keys once
• Allows a more efficient implementation of the Entry api. Which will always be a single hashtable operation.
  • Previously, building the entry would lookup the hashtable once, and other operations would do another lookup (e.g. OccupiedEntry::remove or VacantEntry::insert).
• Allows dashmap raw api to be safely exposed even with the improvements above, as the shards are raw tables w/o hashers. This will avoid problems like https://github.com/xacrimon/dashmap/pull/259. crates.io use case (iterate the removed shards) will still be possible with rawtables.
• Removes a lot of generic types for the hasher
• Slightly simplifies some code paths as we don't have to fight lifetimes

The first two can be significant performance improvements in some circumstances.

Sadly, this is a breaking change for raw-api users so it'll require a major version bump.

Maybe the third time is the charm :smile:

[conradludgate]

A potentially nicer setup could be to use the new HashTable API instead of RawTable. I put together a WIP of that in this commit https://github.com/conradludgate/dashmap/commit/3023a51babdb37fb08252b25a0d7dc1c1ae846d8.

[arthurprs]

The downside with Hashtable is still has all the lifetimes and that doesn't play well with dashmap lock wrappers. Meaning we keep having to transmute lifetimes at every corner with change_lifetime_const, etc..