Use hashbrown::HashTable instead of RawTable

[cuviper]

No description provided.

[cuviper]

I previously considered this in #280, and it didn't seem beneficial at the time, but now hashbrown has removed the "raw" feature for its upcoming 0.15. So we'll either have to make the move, or stay on 0.14 and possibly think about forking.

On the idea of forking -- I wonder if much could be gained by hard-coding that we always use RawTable<usize>, e.g. we never have to worry about dropping items. We could also get fancy and use u32 (or even u16) when the capacity is low enough, reducing memory usage -- as the pre-hashbrown version of this crate did!

[cuviper]

I wonder if much could be gained by hard-coding that we always use RawTable<usize>,

I tested this in rustc, but it didn't show any noticeable change in compiler performance: rust-lang/rust#129965

[clarfonthey]

Just popping in to say that since I'm going to be working a lot on moving over hashbrown to use the HashTable API internally and completely get rid of the RawTable API, and would definitely be paying attention to any feedback you have if you shared it here: rust-lang/hashbrown#545

The raw table API is very messy and was designed before MaybeUninit existed, which is why we wanted to redo it.

[cuviper]

@clarfonthey Just to highlight, this comment is the part that I find most unfortunate about the change: it makes our OccupiedEntry larger to carry separate &mut references, and also makes the core methods more awkward to call from the entry. This new RefMut recovers some of the ergonomics, but I don't know that it's possible to avoid the size increase at all.

Before, raw::Bucket allowed me to store that with the full &mut IndexMapCore in the entry.

[clarfonthey]

Hmm, yeah, I should add that one thing I definitely want to improve is all of the wasted space in a lot of the internal types.