Consider extracting RawTable into a separate crate

[stepancheg]

There are two issues with RawTable being in hashbrown crate:

• extra "feature" in hashbrown crate makes it slightly harder to use (for both crate authors and for users)
• unnecessary HashMap type in all crates namespaces

About the latter.

We use RawTable heavily, but we don't use hashbrown::HashMap (because it is virtually identical to std). But when doing code completion, hashbrown::HashMap often pops up instead of std::collections::HashMap. And once in a while it even accidentally slips into committed code.

Extracting RawTable in a separate crate would solve this issue.

This is not a big deal, feel free to close the issue if this is not right.

[cuviper]

There would also be some compile-time benefit. Just now I was playing with feature-gating the map/set code, and using --no-default-features --features raw went from 0.43s to 0.21s on my Ryzen 5800X. That's not going to be a big deal in the scope of a full project, but it's an improvement nonetheless.

So it doesn't literally have to be a separate crate if the default features are reduced to basically nothing. Separating the semver of RawTable might be useful otherwise though, like if API changes are coordinated with std that don't have any effect on raw users.

I also wonder if std could benefit from stripping the shim HashMap/Set wrappers to use RawTable itself, but that's a bigger consideration.