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]
@pczarn @gereeter  For the sake of pushing this through, I've settled on the more efficient but potentially unintuitive (wrt to Key ownership) solution you're both been pushing for. I 99.99% agree with you guys, I'm just iffy because this can exclude some niche applications. Now that only values are being swapped, set can trivially take `&mut self` now, improving composability further. I have adjusted the API accordingly.