We have `File::create` for creating a file or opening an existing file,
but the secure way to guarantee creating a new file requires a longhand
invocation via `OpenOptions`.

Add `File::create_new` to handle this case, to make it easier for people
to do secure file creation.

I refactored the code:
- Removed handling of methods, as it felt entirely unnecessary
- Removed clippy utils (obviously...)
- Used some shiny compiler features
  (let-else is very handy for lints 👀)
- I also renamed the lint to `for_loop_over_fallibles` (note: no `s`).
  I'm not sure what's the naming convention here, so maybe I'm wrong.

if the iterator is used after the loop, we need to use `.by_ref()`

The loop could contain `break;` that won't work with an `if let`

…nitialized Scalar

Continuation of rust-lang#100938 and rust-lang#101010. This rule was added to support the old,
table-based style for displaying enum variants, which are now displayed using
headers and paragraphs.

Add a `File::create_new` constructor

We have `File::create` for creating a file or opening an existing file,
but the secure way to guarantee creating a new file requires a longhand
invocation via `OpenOptions`.

Add `File::create_new` to handle this case, to make it easier for people
to do secure file creation.

Uplift `clippy::for_loops_over_fallibles` lint into rustc

This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.

There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
   ```rust
    for _ in iter.next() {}
    // turns into
    for _ in iter.by_ref() {}
    ```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
   ```rust
   for _ in rx.recv() {}
   // turns into
   while let Some(_) = rx.recv() {}
   ```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
   ```rust
   for _ in f() {}
   // turns into
   for _ in f()? {}
   ```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
   ```rust
   for _ in f() {}
   // turns into
   if let Some(_) = f() {}
   ```
(P.S. `Some` and `Ok` are interchangeable depending on the type)

I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!

Resolves rust-lang#99272

[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles

Add comments about stdout locking

This is the source of some confusion regarding the `println!` macro:
* https://llogiq.github.io/2017/06/01/perf-pitfalls.html#unbuffered-io
* https://news.ycombinator.com/item?id=18794930
* https://reddit.com/r/rust/comments/5puyx2/why_is_println_so_slow/dcua5g5/
* https://reddit.com/r/rust/comments/ab7hsi/comparing_pythagorean_triples_in_c_d_and_rust/ecy7ql8/

In some of these cases it's not the locking behavior where the bottleneck lies, but it's still mentioned as a surprise when, eg, benchmarking a million `println!`'s in a very tight loop.

If there's any stylistic problems please feel free to correct me! This is my first contribution and I want to get it right 🦀

…-obk

interpret: remove support for uninitialized scalars

With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.

I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.

Fixes rust-lang/miri#2187
r? ````@oli-obk````

…tch-err, r=oli-obk

Improve const mismatch `FulfillmentError`

Fixes rust-lang#100414

…, r=thomcc

Use `DisplayBuffer` for socket addresses.

Continuation of rust-lang#100625 for socket addresses.

Renames `net::addr` to `net::addr::socket`, `net::ip` to `net::addr::ip` and `net::ip::display_buffer::IpDisplayBuffer` to `net::addr::display_buffer::DisplayBuffer`.

…-session-diagnostic, r=davidtwco

Migrate ast lowering to session diagnostic

I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see rust-lang#100694).

extra sanity check against consts pointing to mutable memory

This should be both unreachable and redundant (since we already ensure that validation only reads from read-only memory, when validating consts), but I feel like we cannot be paranoid enough here, and also if this ever fails it'll be a nicer error than the "cannot read from mutable memory" error.

…, r=jsha

rustdoc: remove unused CSS for `.variants_table`

Continuation of rust-lang#100938 and rust-lang#101010. This rule was added to support the old, table-based style for displaying enum variants, which are now displayed using headers and paragraphs.