implement entry API for HashMap

Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree` is part of the complete rewrite in #17334.

The implemented API deviates from the API described in the RFC in two key places:

* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.

This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.

[breaking-change]
So, you're not wrong. However there's a few reasons I'm inclined to leave it:

* This also swaps the keys, which is the defacto "map" behavior. Not holding onto the key would prevent this. (You could still lose the hash and just use mem::swap, though)
* This directly uses the intended internal API for doing this.
* VacantEntry is already bigger than OccupiedEntry, and since they're always acquired through matching on an enum, you probably won't actually have any space savings
* It's programmatically simpler than doing a mem::swap

However on balance it's probably a wash. If you feel strongly about it, I can make the change.