Fix some clippy lints for library/std/src/sys/windows

These issues were shown by running `x clippy` on `library/std` and filtering for `windows/` paths. I think running clippy on the full std would be great but I wanted to start smaller and with something that's hopefully easier to review. It'd be good to eventually run clippy in CI but that's a bigger conversation.

I've created separate commits for each clippy lint fixed (with the commit title set to the lint name) and reviewed the changes myself. Most of the fixes here are trivial.

r? libs

Remove `PredicateKind::ClosureKind`

We don't need the `ClosureKind` predicate kind -- instead, `Fn`-family trait goals are left as ambiguous, and we only need to make progress on `FnOnce` projection goals for inference purposes.

This is similar to how we do confirmation of `Fn`-family trait and projection goals in the new trait solver, which also doesn't use the `ClosureKind` predicate.

Some hacky logic is added in the second commit so that we can keep the error messages the same.

…rors

Rollup of 6 pull requests

Successful merges:

 - #118012 (Add support for global allocation in smir)
 - #118013 (Enable Rust to use the EHCont security feature of Windows)
 - #118100 (Enable profiler in dist-powerpc64-linux)
 - #118142 (Tighten up link attributes for llvm-wrapper bindings)
 - #118147 (Fix some unnecessary casts)
 - #118161 (Allow defining opaques in `check_coroutine_obligations`)

r? `@ghost`
`@rustbot` modify labels: rollup

…s, r=lcnr

Allow defining opaques in `check_coroutine_obligations`

In the new trait solver, when an obligation stalls on an unresolved coroutine witness, we will stash away the *root* obligation, even if the stalled obligation is only a distant descendent of the root obligation, since the new solver is purely recursive.

This means that we may need to reprocess alias-relate obligations (and others) which may define opaque types in the new solver. Currently, we use the coroutine's def id as the defining anchor in `check_coroutine_obligations`, which will allow defining no opaque types, resulting in errors like:

```
error[E0271]: type mismatch resolving `{coroutine@<source>:6:5: 6:17} <: impl Clone`
 --> <source>:6:5
  |
6 | /     move |_: ()| {
7 | |         let () = yield ();
8 | |     }
  | |_____^ types differ
```

So this PR fixes the defining anchor and does the same trick as `check_opaque_well_formed`, where we manually compare opaques that were defined against their hidden types to make sure they weren't defined differently when processing these stalled coroutine obligations.

r? `@lcnr` cc `@cjgillot`

Fix some unnecessary casts

`x clippy compiler -Aclippy::all -Wclippy::unnecessary_cast --fix` with some manual review to ensure every fix is correct.

Tighten up link attributes for llvm-wrapper bindings

Fixes #118084 by moving all of the declarations of symbols from `llvm_rust` into a separate extern block with `#[link(name = "llvm-wrapper", kind = "static")]`.

This also renames `LLVMTimeTraceProfiler*` to `LLVMRustTimeTraceProfiler*` because those are functions from `llvm_rust`.

r? tmiasko

Enable profiler in dist-powerpc64-linux

Enable Rust to use the EHCont security feature of Windows

In the future Windows will enable Control-flow Enforcement Technology (CET aka Shadow Stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.

The required support for EHCONT Guard has already been merged into LLVM, long ago. This change simply adds the Rust codegen option to enable it.

Relevant LLVM change: https://reviews.llvm.org/D40223

This also adds a new `ehcont-guard` option to the bootstrap config which enables EHCont Guard when building std.

We at Microsoft have been using this feature for a significant period of time; we are confident that the LLVM feature, when enabled, generates well-formed code.

We currently enable EHCONT using a codegen feature, but I'm certainly open to refactoring this to be a target feature instead, or to use any appropriate mechanism to enable it.

Add support for global allocation in smir

Add APIs to StableMir to support global allocation. Before this change, StableMir users had no API available to retrieve Allocation provenance information. They had to resource to internal APIs instead.

One example is retrieving the Allocation of an `&str`. See test for an example on how the API can be used.

Stabilize RFC3324 dyn upcasting coercion

This PR stabilize the `trait_upcasting` feature, aka rust-lang/rfcs#3324.

The FCP was completed here: #65991 (comment).

~~And also remove the `deref_into_dyn_supertrait` lint which is now handled by dyn upcasting coercion.~~

Heavily inspired by #101718
Fixes #65991

Add allow-by-default lint for unit bindings

### Example

```rust
#![warn(unit_bindings)]

macro_rules! owo {
    () => {
        let whats_this = ();
    }
}

fn main() {
    // No warning if user explicitly wrote `()` on either side.
    let expr = ();
    let () = expr;
    let _ = ();

    let _ = expr; //~ WARN binding has unit type
    let pat = expr; //~ WARN binding has unit type
    let _pat = expr; //~ WARN binding has unit type

    // No warning for let bindings with unit type in macro expansions.
    owo!();

    // No warning if user explicitly annotates the unit type on the binding.
    let pat: () = expr;
}
```

outputs

```
warning: binding has unit type `()`
  --> $DIR/unit-bindings.rs:17:5
   |
LL |     let _ = expr;
   |     ^^^^-^^^^^^^^
   |         |
   |         this pattern is inferred to be the unit type `()`
   |
note: the lint level is defined here
  --> $DIR/unit-bindings.rs:3:9
   |
LL | #![warn(unit_bindings)]
   |         ^^^^^^^^^^^^^

warning: binding has unit type `()`
  --> $DIR/unit-bindings.rs:18:5
   |
LL |     let pat = expr;
   |     ^^^^---^^^^^^^^
   |         |
   |         this pattern is inferred to be the unit type `()`

warning: binding has unit type `()`
  --> $DIR/unit-bindings.rs:19:5
   |
LL |     let _pat = expr;
   |     ^^^^----^^^^^^^^
   |         |
   |         this pattern is inferred to be the unit type `()`

warning: 3 warnings emitted
```

This lint is not triggered if any of the following conditions are met:

- The user explicitly annotates the binding with the `()` type.
- The binding is from a macro expansion.
- The user explicitly wrote `let () = init;`
- The user explicitly wrote `let pat = ();`. This is allowed for local lifetimes.

### Known Issue

It is known that this lint can trigger on some proc-macro generated code whose span returns false for `Span::from_expansion` because e.g. the proc-macro simply forwards user code spans, and otherwise don't have distinguishing syntax context compared to non-macro-generated code. For those kind of proc-macros, I believe the correct way to fix them is to instead emit identifers with span like `Span::mixed_site().located_at(user_span)`.

Closes #71432.

comparing with null is better expressed by the `.is_null()` method

taken reference of right operand

manual implementation of `Option::map`

unnecessary closure used with `bool::then`

calling `subsec_micros()` is more concise than this calculation

casting to the same type is unnecessary

this expression creates a reference which is immediately dereferenced by the compiler

the borrowed expression implements the required traits

This is where our Windows API bindings previously (and incorrectly) used `*mut` instead of `*const` pointers. Now that the bindings have been corrected, the mutable references (which auto-convert to `*mut`) are unnecessary and we can use shared references.

unneeded `return` statement

Aka trait_upcasting feature.

And also adjust the `deref_into_dyn_supertrait` lint.

Queries cleanups

r? `@bjorn3`

Make some `newtype_index!` derived impls opt-in instead of opt-out

Opt-in is the standard Rust way of doing things, and avoids some unnecessary dependencies on the `rustc_serialize` crate.

r? `@lcnr`

Similar to the previous commit, this replaces `newtype_index`'s opt-out
`no_ord_impl` attribute with the opt-in `orderable` attribute.

By default, `newtype_index!` types get a default `Encodable`/`Decodable`
impl. You can opt out of this with `custom_encodable`. Opting out is the
opposite to how Rust normally works with autogenerated (derived) impls.

This commit inverts the behaviour, replacing `custom_encodable` with
`encodable` which opts into the default `Encodable`/`Decodable` impl.
Only 23 of the 59 `newtype_index!` occurrences need `encodable`.

Even better, there were eight crates with a dependency on
`rustc_serialize` just from unused default `Encodable`/`Decodable`
impls. This commit removes that dependency from those eight crates.

Remove `feature` from the list of well known check-cfg name

This PR removes `feature` from the list of well known check-cfg.

This is done for multiple reasons:
 - Cargo is the source of truth, rustc shouldn't have any knowledge of it
 - It creates a conflict between Cargo and rustc when there are no features defined.
   In this case Cargo won't pass any `--check-cfg` for `feature` since no feature will ever be passed, but rustc by having in it's list adds a implicit `cfg(feature, values(any()))` which is completely wrong. Having any cfg `feature` is unexpected not allow any `feature` value.

While doing this, I took the opportunity to specialise the diagnostic a bit for the case above.

r? `@petrochenkov`

`rustc_ast_pretty` cleanups

Some improvements I found while looking at this code.

r? `@fee1-dead`