handle user type annotations in NLL for `ref` bindings

[pnkfelix]

spun off from #47184 and #54570 :

Most of the necessary support for checking lifetime constraints introduced via complex patterns has been added. But one exceptional case which has not been properly dealt with is ref bindings.

If you look here the code explicitly says "ignore pattern_user_ty for now."

rust/src/librustc_mir/build/matches/mod.rs

Lines 518 to 526 in 3e6f30e

	BindingMode::ByRef(..) => {
	// If this is a `ref` binding (e.g., `let ref
	// x: T = ..`), then the type of `x` is not
	// `T` but rather `&T`, so ignore
	// `pattern_user_ty` for now.
	//
	// FIXME(#47184): extract or handle `pattern_user_ty` somehow
	pattern_user_ty = None;
	}

(I fixed a lot of instances of FIXME(#47184) in PR #55274, but I punted on this one.)

[nikomatsakis]

@pnkfelix do you have an example of a program that fails to error as a result of this bug?

[pnkfelix]

I think this should error, but does not under NLL today:

fn static_to_a_to_static_through_ref_in_tuple<'a>(x: &'a u32) -> &'static u32 {
    let (ref y, _z): (&'a u32, u32) = (&22, 44);
    *y //~ ERROR
}

[pnkfelix]

(this may not be that hard to fix. I punted because the other cases seemed way more important to get fixed ASAP, but its possible that a similar pattern can work for this too.)

[pnkfelix]

I don't think any fix for this is worth the effort of backporting, though... its a really subtle case.

[davidtwco]

Update: Got confused by migration mode, this isn't fixed.

The test case in this issue now errors correctly under NLL, seems to have been changed by #55274, but that PR description says:

Oh, one more thing: This doesn't attempt to handle ref x (in terms of ensuring that any necessary types are ascribed to x in that scenario as well). We should open an issue to investigate supporting that as well. But I didn't want to block this PR on that future work.