The initial `minicore` is intentionally super minimal and contains an
incomplete subset of `core` items, and explicitly not items from `alloc`
or `std`-only items.

…st module

… directive

…lude when requested via `//@ add-core-stubs` directive

`//@ add-core-stubs` will imply `-Cpanic=abort`.

Check that `minicore` cannot be used with `run-{pass,fail}` tests.

Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests

Context: [Real cross-compiling tests instead of `#![no_core]` silliness rust-lang#130375](rust-lang#130375)
MCP: rust-lang/compiler-team#786
Tracking issue: rust-lang#131485

This prototype PR is subject to further changes based on feedback.

### New `minicore` test auxiliary and `//@ add-core-stubs` compiletest directive

This PR introduces a prototype implementation of a `minicore` auxiliary test helper that provides `core` stubs for `#![no_core]` ui/assembly/codegen tests that need to build but not run on both the host platform and the cross-compiled target platform.

Key summary:

- `tests/auxiliary/minicore.rs` contains stub definitions of `core` items intended for consumption by `check-pass`/`build-pass` tests that want the typical prelude items like `Copy` to be stubbed out under `#![no_core]` scenarios, so that the test can be built (not run) for cross-compiled target platforms. Such tests don't want nor need full `-Z build-std` (e.g. `tests/ui/abi/compatibility.rs`).
- `minicore` is intended for `core` items **only**, not `std`- or `alloc`-exclusive items. If stubs for `alloc` or `std` are wanted, they should be provided by an additional directive and test auxiliary, and not be conflated with `minicore` or `core` stubs. This is because a wider range of tests can benefit from `core`-only stubs.

### Implementation

- The `minicore` auxiliary is a single source file `tests/auxiliary/minicore.rs`.
- The path to `minicore` is made avaiable from bootstrap to compiletest via the `--minicore-path` compiletest flag.
- `minicore` is then built on-demand via the `//@ add-core-stubs` compiletest directive, for each test revision for the given target platform (this distinction is important for when host platform != target platform in cross-compilation scenario).
- `minicore` is then made available to the test as an [extern prelude].

[extern prelude]: https://doc.rust-lang.org/reference/names/preludes.html#extern-prelude

### Example usage

```rs
// tests/ui/abi/my-abi-test.rs

//@ check-pass
//@ add-core-stubs
//@ compile-flags: --target i686-unknown-linux-gnu
//@ needs-llvm-components: x86

#![feature(no_core, lang_items)]
#![no_std]
#![no_core]
#![allow(unused, internal_features)]

extern crate minicore;
use minicore::*;

#[lang = "clone"]
pub trait Clone: Sized {      // `Sized` is provided by `minicore`
    fn clone(&self) -> Self;
}
```

### Implementation steps

- [x] 1. Add an initial `minicore` test auxiliary.
- [x] 2. Build `minicore` in bootstrap.
- [x] 3. Setup a `--minicore-path` compiletest cli flag and pass `minicore` build artifact path from bootstrap to compiletest.
- [x] 4. Assert `add-core-stubs` is mutually incompatible with tests that require to be `run`, as the stubs are only good for tests that only need to be built (i.e. no `run-{pass,fail}`).
- [x] 5. Add some self-tests to sanity check the behavior.
- [x] 6. Ensure that `tests/auxiliary/minicore.rs` is input stamped, i.e. modifying `tests/auxiliary/minicore.rs` should invalidate test cache and force the test to be rerun.

### Known limitations

- The current `minicore` is very minimal, because this PR is intended to focus on supporting the test infrastructure first. Further stubs could be added in follow-up PRs and/or on a as-needed basis.

try-job: aarch64-apple
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: test-various
try-job: dist-various-1

… r=Mark-Simulacrum

CI: use free runners for 3 fast windows jobs

try-job: dist-i686-msvc
try-job: dist-i686-mingw
try-job: dist-x86_64-mingw
try-job: dist-x86_64-msvc-alt

Add `lp64e` RISC-V ABI

This PR adds support for the `lp64e` RISC-V ABI, which is the 64-bit equivalent of the `ilp32e` ABI that is already supported.

For reference, this ABI was originally added to LLVM in [this PR](https://reviews.llvm.org/D70401).

coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable

In rust-lang#132124, `coverage_cx()` was changed to panic if the context was unavailable, under the assumption that it would always be available whenever coverage instrumentation is enabled.

However, there have been reports of this change causing ICEs in `polars` CI.

I don't yet understand why this is happening, but for now it seems wisest to revert that part of the change, restoring the two early returns that had been replaced with panics.

…x86_64-gnu-tools-and-x86_64-rust-for-linux, r=Kobzol

CI: use free runners for x86_64-gnu-tools and x86_64-rust-for-linux

try-job: x86_64-gnu-tools
try-job: x86_64-rust-for-linux