Replace per-target ABI denylist with an allowlist

It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.

This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.

In this PR we got rid of the per-target ABI denylists, and instead compute
which ABIs are supported with a simple match based on, mostly, the
`Target::arch` field. Among other things, this makes it impossible to
forget to consider this problem (in either direction) and forces one to
consider what the ABI support looks like when adding an ABI (rarely)
rather than target (often), which should hopefully also reduce the
cognitive load on both contributors as well as reviewers.

Fixes #57182

Sponsored by: standard.ai

---

## Summary for teams

One significant user-facing change after this PR is that there's now a future compat warning when building…

* `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*;
* `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*.

Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another.

The intention is that this warning becomes a hard error after some time.

Reland "Merge CrateDisambiguator into StableCrateId"

Reverts https://github.com/rust-lang/rust/pull/85891 as this revert of #85804 made perf even worse.

r? `@Mark-Simulacrum`

It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.

This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.

Fixes #57182

Sponsored by: standard.ai

This reverts commit 8d5fb5bf.

This reverts commit 715c68fe.

This reverts commit 6c5b6985.

This reverts commit 8176ab8b.

Store macro parent module in ExpnData.

As a consequence, its value is hashed as part of the ExpnId's stable hash.

Closes #85999

rustdoc: Replace `FakeDefId` with new `ItemId` type

Follow up from #84707

`@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s.

This type is introduced by this PR.

There are still some `FIXME`s left, because I was unsure what the best solution for them would be.

Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too?

Also, we need to represent the new item ids in the JSON backend somehow.

Cleanup the computation of lint levels

This now uses an `IndexVec` and a special root `LintStackIndex = 0` to encode command-line levels.

Remove LibSource

The information is stored in used_crate_source too anyway.

Split out of #86105

r? `@petrochenkov`

Rollup of 7 pull requests

Successful merges:

 - #83581 (Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStr)
 - #85377 (aborts: Clarify documentation and comments)
 - #86685 (double-check mutability inside Allocation)
 - #86794 (Stabilize `Seek::rewind()`)
 - #86852 (Remove some doc aliases)
 - #86878 (⬆ rust-analyzer)
 - #86886 (Remove `impl Clean for {Ident, Symbol}`)

Failed merges:

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

This reverts commit 41a345d4c46dad1a98c9993bc78513415994e8ba.

Remove `impl Clean for {Ident, Symbol}`

These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.

Found while reviewing https://github.com/rust-lang/rust/pull/86841, which makes the same change to `build_macro`, so the two will conflict.

r? `@GuillaumeGomez`

⬆ rust-analyzer

Remove some doc aliases

As per the new doc alias policy in https://github.com/rust-lang/std-dev-guide/pull/25, this removes some controversial doc aliases:
- `malloc`, `alloc`, `realloc`, etc.
- `length` (alias for `len`)
- `delete` (alias for `remove` in collections and also file/directory deletion)

r? `@joshtriplett`

Stabilize `Seek::rewind()`

This stabilizes `Seek::rewind`. It seemed to fit into one of the existing tests, so I extended that test rather than adding a new one.

Closes #85149.

double-check mutability inside Allocation

r? `@oli-obk`

aborts: Clarify documentation and comments

In the docs for intrinsics::abort():

 * Strengthen the recommendation by to use process::abort instead.
 * Document the fact that it sometimes (ab)uses an LLVM debug trap and what the likely consequences are.
 * State that the precise behaviour is unstable.

In the docs for process::abort():

 * Promise that we have the same behaviour as C `abort()`.
 * Document the likely consequences, including, specifically, the consequences on Unix.

In the internal comment for unix::abort_internal:

 * Refer to the public docs for the public API functions.
 * Correct and expand the description of libc::abort.  Specifically:
 * Do not claim that abort() unregisters signal handlers.  It doesn't; it honours the SIGABRT handler.
 * Discuss, extensively, the issue with abort() flushing stdio buffers.
 * Describe the glibc behaviour in some detail.
Co-authored-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Fixes #40230

Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStr

Greetings!

This is my first PR here, so please forgive me if I've missed an important step or otherwise done something wrong. I'm very open to suggestions/fixes/corrections.

This PR adds a function that allows `std::fs::DirEntry` to vend a borrow of its filename on Unix platforms, which is especially useful for sorting. (Windows has (as I understand it) encoding differences that require an allocation.) This new function sits alongside the cross-platform [`file_name(&self) -> OsString`](https://doc.rust-lang.org/std/fs/struct.DirEntry.html#method.file_name) function.

I pitched this idea in an [internals thread](https://internals.rust-lang.org/t/allow-std-direntry-to-vend-borrows-of-its-filename/14328/4), and no one objected vehemently, so here we are.

I understand features in general, I believe, but I'm not at all confident that my whole-cloth invention of a new feature string (as required by the compiler) was correct (or that the name is appropriate). Further, there doesn't appear to be a test for the sibling `ino` function, so I didn't add one for this similarly trivial function either. If it's desirable that I should do so, I'd be happy to [figure out how to] do that.

The following is a trivial sample of a use-case for this function, in which directory entries are sorted without any additional allocations:

```rust
use std::os::unix::fs::DirEntryExt;
use std::{fs, io};

fn main() -> io::Result<()> {
    let mut entries = fs::read_dir(".")?.collect::<Result<Vec<_>, io::Error>>()?;
    entries.sort_unstable_by(|a, b| a.file_name_ref().cmp(b.file_name_ref()));

    for p in entries {
        println!("{:?}", p);
    }

    Ok(())
}
```

Query-ify global limit attribute handling

Currently, we read various 'global limits' from inner attributes the crate root (`recursion_limit`, `move_size_limit`, `type_length_limit`, `const_eval_limit`). These limits are then stored in `Sessions`, allowing them to be access from a `TyCtxt` without registering a dependency on the crate root attributes.

This PR moves the calculation of these global limits behind queries, so that we properly track dependencies on crate root attributes. During the setup of macro expansion (before we've created a `TyCtxt`), we need to access the recursion limit, which is now done by directly calling into the code shared by the normal query implementations.