…nikomatsakis

Stabilize `let` bindings and destructuring in constants and const fn

r? @Centril

This PR stabilizes the following features in constants and `const` functions:

* irrefutable destructuring patterns (e.g. `const fn foo((x, y): (u8, u8)) { ... }`)
* `let` bindings (e.g. `let x = 1;`)
* mutable `let` bindings (e.g. `let mut x = 1;`)
* assignment (e.g. `x = y`) and assignment operator (e.g. `x += y`) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like `x[3] = 42`)
* expression statements (e.g. `3;`)

This PR does explicitly *not* stabilize:

* mutable references (i.e. `&mut T`)
* dereferencing mutable references
* refutable patterns (e.g. `Some(x)`)
* operations on `UnsafeCell` types (as that would need raw pointers and mutable references and such, not because it is explicitly forbidden. We can't explicitly forbid it as such values are OK as long as they aren't mutated.)
* We are not stabilizing `let` bindings in constants that use `&&` and `||` short circuiting operations. These are treated as `&` and `|` inside `const` and `static` items right now. If we stopped treating them as `&` and `|` after stabilizing `let` bindings, we'd break code like `let mut x = false; false && { x = true; false };`. So to use `let` bindings in constants you need to change `&&` and `||` to `&` and `|` respectively.

…li-obk

Const-stabilize `const_int_ops` + `const_ip`

r? @oli-obk

I've added T-lang since this affects intrinsics and the operational semantics of Rust's `const fn` fragment.
This PR depends on rust-lang#57105 but the FCP intent does not.

## Stable APIs proposed for constification

+ `const_int_ops`:
    + `count_ones`
    + `count_zeros`
    + `leading_zeros`
    + `trailing_zeros`
    + `swap_bytes`
    + `from_be`
    + `from_le`
    + `to_be`
    + `to_le`
+ `const_ip`
    + `Ipv4Addr::new`

## Unstable APIs constified

+ `const_int_conversion`:
    + `reverse_bits`