This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.

This is a clearer name since they represent [a, b, c] array literals.

Stage 1 can’t really handle negative 128-bit literals, but an equivalent bit-not is fine

This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.

The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.

In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).

This commit includes manual merge conflict resolution changes from a rebase by @est31.

Removed FIXME comment referencing #3300.

remove `export` argument of `resolver.add_macro()`.

This implements RFC 1624, tracking issue #37339.

- `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s, which store the
  currently deduced type of that loop, the desired type, and a list of
  break expressions currently seen. `loop` loops get a fresh type
  variable as their initial type (this logic is stolen from that for
  arrays). `while` loops get `()`.
- `break {expr}` looks up the broken loop, and unifies the type of
  `expr` with the type of the loop.
- `break` with no expr unifies the loop's type with `()`.
- When building MIR, `loop` loops no longer construct a `()` value at
  termination of the loop; rather, the `break` expression assigns the
  result of the loop. `while` loops are unchanged.
- `break` respects contexts in which expressions may not end with braced
  blocks. That is, `while break { break-value } { while-body }` is
  illegal; this preserves backwards compatibility.
- The RFC did not make it clear, but I chose to make `break ()` inside
  of a `while` loop illegal, just in case we wanted to do anything with
  that design space in the future.

This is my first time dealing with this part of rustc so I'm sure
there's plenty of problems to pick on here ^_^

Given the following code:

```rust
struct Foo<T: Clone>(T);

use std::ops::Add;

impl<T: Clone, Add> Add for Foo<T> {
    type Output = usize;

    fn add(self, rhs: Self) -> Self::Output {
      unimplemented!();
    }
}
```

present the following output:

```nocode
error[E0404]: `Add` is not a trait
 --> file3.rs:5:21
  |
5 | impl<T: Clone, Add> Add for Okok<T> {
  |                ---  ^^^ expected trait, found type parameter
  |                |
  |                type parameter defined here
```

Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.

There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.

`opaque::Decoder::read_str` is very hot within `rustc` due to its use in
the reading of crate metadata, and it currently returns a `String`. This
commit changes it to instead return a `Cow<str>`, which avoids a heap
allocation.

This change reduces the number of calls to `malloc` by almost 10% in
some benchmarks.

This is a [breaking-change] to libserialize.

This applies the HIR changes from the previous commits to the AST, and
is thus a syntax-[breaking-change]

Renames `PatKind::Vec` to `PatKind::Slice`, since these are called slice
patterns, not vec patterns. Renames `TyKind::Vec`, which represents the
type `[T]`, to `TyKind::Slice`. Renames `TyKind::FixedLengthVec` to
`TyKind::Array`.

I am using `ThinAttributes` rather than a vector for attributes
attached to generics, since I expect almost all lifetime and types
parameters to not carry any attributes.