It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related
casts, when in reality their just used to share a some enum variants. Make it clear there these
are only coercion to make it clear why only some pointer related "casts" are in the enum.

To shrink it a little more.

`thir::Pat::kind` is a `Box<PatKind>`, which doesn't follow the usual
pattern in AST/HIR/THIR which is that the "kind" enum for a node is
stored inline within the parent struct.

This commit makes the `PatKind` directly inline within the `Pat`. This
requires using `Box<Pat>` in all the types that hold a `Pat.

Ideally, `Pat` would be stored in `Thir` like `Expr` and `Stmt` and
referred to with a `PatId` rather than `Box<Pat>`. But this is hard to
do because lots of `Pat`s get created after the destruction of the `Cx`
that does normal THIR building. But this does get us a step closer to
`PatId`, because all the `Box<Pat>` occurrences would be replaced with
`PatId` if `PatId` ever happened.

At 128 bytes, `Pat` is large. Subsequent commits will shrink it.

This matches the naming scheme used elsewhere, e.g. in the AST, and
avoids name clashes with the `ExprKind::Closure` variant.

This shrinks `thir::Expr`.

This shrinks `thir::Expr`.

Like expressions, statements, and match arms. This shrinks `thir::Stmt`
and is a precursor to further shrinking `thir::Expr`.

There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
  `ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.

So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.

When constructing a MIR from a THIR field expression, introduce an
additional downcast projection before accessing a field of an enum.

When rebasing a place builder on top of a captured place, account for
the fact that a single HIR enum field projection corresponds to two MIR
projection elements: a downcast element and a field element.

use NonHirLiteral instead of ScalarLiteral, move pattern related code to pat_is_poly in IsThirPolymorphic

This reverts commit a240ccd8, reversing
changes made to 393fdc10.

This PR was likely responsible for a relatively large regression in
dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
bringing that builder into the pool of the slowest builders we currently have.

This seems to be limited to the alt builder due to needing parallel-compiler
enabled, likely leading to slow LLVM compilation for some reason.

Specifically, rename the `Const` struct as `ConstS` and re-introduce `Const` as
this:
```
pub struct Const<'tcx>(&'tcx Interned<ConstS>);
```
This now matches `Ty` and `Predicate` more closely, including using
pointer-based `eq` and `hash`.

Notable changes:
- `mk_const` now takes a `ConstS`.
- `Const` was copy, despite being 48 bytes. Now `ConstS` is not, so need a
  we need separate arena for it, because we can't use the `Dropless` one any
  more.
- Many `&'tcx Const<'tcx>`/`&Const<'tcx>` to `Const<'tcx>` changes
- Many `ct.ty` to `ct.ty()` and `ct.val` to `ct.val()` changes.
- Lots of tedious sigil fiddling.