Previously, a Drop terminator was considered a move in MIR.
This commit changes the behavior to only treat Drop as a mutable
access to the dropped place.

In order for this change to be correct, we need to guarantee that
  a) A dropped value won't be used again
  b) Places that appear in a drop won't be used again before a
     subsequent initialization.

We can ensure this to be correct at MIR construction because Drop
will only be emitted when a variable goes out of scope,
thus having:
  (a) as there is no way of reaching the old value. drop-elaboration
     will also remove any uninitialized drop.
  (b) as the place can't be named following the end of the scope.

However, the initialization status, previously tracked by moves,
should also be tied to the execution of a Drop, hence the
additional logic in the dataflow analyses.

This is a prerequisite for cursor support for `BTreeMap`.

Implement cursors for BTreeMap

See the ACP for an overview of the API: rust-lang/libs-team#141

The implementation is split into 2 commits:
- The first changes the internal insertion functions to return a handle to the newly inserted element. The lifetimes involved are a bit hairy since we need a mutable handle to both the `BTreeMap` itself (which holds the root) and the nodes allocated in memory. I have tested that this passes the standard library testsuite under miri.
- The second commit implements the cursor API itself. This is more straightforward to follow but still involves some unsafe code to deal with simultaneous mutable borrows of the tree root and the node that is currently being iterated.

Treat Drop as a rmw operation

Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.

In order for this change to be correct, we need to guarantee that

1.  A dropped value won't be used again
   2.  Places that appear in a drop won't be used again before a
     subsequent initialization.

We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
*   (1) as there is no way of reaching the old value. drop-elaboration
     will also remove any uninitialized drop.
 * (2) as the place can't be named following the end of the scope.

However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.

From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from rust-lang/compiler-team#558.
See also rust-lang#104488 (comment)

Change `arena_cache` to not alter the declared query result

This makes the return types a bit clearer, limiting `arena_cache`'s effect to just the computation side. It also makes it easier to potentially remove `arena_cache`.

r? `@cjgillot`

…lly-derive-const, r=fee1-dead

Make `derive_const` derive properly const-if-const impls

Fixes rust-lang#107774
Fixes rust-lang#107666

Also fixes rendering of const-if-const bounds in pretty printing.

r? `@oli-obk` or `@fee1-dead`

…, r=lcnr

Rename `replace_bound_vars_with_*` to `instantiate_binder_with_*`

Mentioning "binder" rather than "bound vars", imo, makes it clearer that we're doing something to the binder as a whole.

Also, "instantiate" is the verb that I'm always reaching for when I'm looking for these functions, and the name that we use in the new solver anyways.

r? types

…=Dylan-DPC

Add missing tracking issue for `RawOsError`

I forgot to add it in the original PR…

See rust-lang#107792.

`@rustbot` label +T-libs-api -T-libs