Instead, filter out (non-)conflicts of activiations with themselves in
the same manner that we filter out non-conflict between an activation
and its reservation.

Address review note: `AccessErrorsReported` meant to track whether error reported at *any* point in past.

Since we are now checking activation points, I removed one of the
checks at the reservation point. (You can see the effect this had on
two-phase-reservation-sharing-interference-2.rs)

Also, since we now have checks at both the reservation point and the
activation point, we sometimes would observe duplicate errors (since
either one independently interferes with another mutable borrow).  To
deal with this, I used a similar strategy to one used as discussed on
issue #45360: keep a set of errors reported (in this case for
reservations), and then avoid doing the checks for the corresponding
activations. (This does mean that some errors could get masked, namely
for conflicting borrows that start after the reservation but still
conflict with the activation, which is unchecked when there was an
error for the reservation. But this seems like a reasonable price to
pay.)

two-phase `&mut`-borrow support.

This (new) support sits under `-Z two-phase-borrows` debugflag.

(Still needs tests. That's coming next.)

High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).

The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)

The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.

 * Incorporating the output from one dataflow analysis into the input
   of another required more changes to the infrastructure than I had
   expected, and even after those changes, the resulting code is still
   a bit subtle.

 * In particular, Since we need to know the intrablock reservation
   state, we need to dynamically update a bitvector for the
   reservations as we are also trying to compute the gen/kills
   bitvector for the active borrows.

 * The way I ended up deciding to do this (after also toying with at
   least two other designs) is to put both the reservation state and
   the active borrow state into a single bitvector. That is why we now
   have separate (but related) `BorrowIndex` and
   `ReserveOrActivateIndex`: each borrow index maps to a pair of
   neighboring reservation and activation indexes.

As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.

But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via

```rust
 #[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
             borrowck_graphviz_postflow="post_two_phase.dot")]
```

Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.

Made `do_dataflow` and related API `pub(crate)`.

This fixes the handling of reassignment of struct fields.

We can now use it in e.g. drop elaboration if we want to.

The borrow_check module is too big for its own good

Fixes #45638

This fixes the tests for issue #29793

I'm not sure how correct it this, but it gets whatever needs to compile
to compile.

This improves performance on large functions.

Fixes #44831.
Fixes #44834.
Fixes #45537.
Fixes #45696 (by implementing DerefPure semantics, which is what we want
going forward).

In particular, if we see a variable is DROP-LIVE, but it is not
MAYBE-INIT, then we can ignore the drop. This leavess attempt to use
more complex refinements of the idea (e.g., for subpaths or subfields)
to future work.

Matches current ast-borrowck behavior.