The "dragon" `flt2dec` algorithm uses multi-precision multiplication by
(sometimes large) powers of 10. It has precomputed some values to help
with these calculations.

BUT:

* There is no need to store powers of 10 and 2 * powers of 10: it is
  trivial to compute the second from the first.
* We can save a chunk of memory by storing powers of 5 instead of powers
  of 10 for the large powers (and just shifting by 2 as appropriate).
* This also slightly speeds up the routines (by ~1-3%) since the
  intermediate products are smaller and the shift is cheap.

In this PR, we remove the unnecessary constants and do the necessary
adjustments.

Relevant benchmarks before (on my Threadripper 3970X, x86_64-unknown-linux-gnu):

```
num::flt2dec::bench_big_shortest                      137.92/iter   +/- 2.24
num::flt2dec::strategy::dragon::bench_big_exact_12   2135.28/iter  +/- 38.90
num::flt2dec::strategy::dragon::bench_big_exact_3     904.95/iter  +/- 10.58
num::flt2dec::strategy::dragon::bench_big_exact_inf 47230.33/iter +/- 320.84
num::flt2dec::strategy::dragon::bench_big_shortest   3915.05/iter  +/- 51.37
```

and after:

```
num::flt2dec::bench_big_shortest                      137.40/iter   +/- 2.03
num::flt2dec::strategy::dragon::bench_big_exact_12   2101.10/iter  +/- 25.63
num::flt2dec::strategy::dragon::bench_big_exact_3     873.86/iter   +/- 4.20
num::flt2dec::strategy::dragon::bench_big_exact_inf 47468.19/iter +/- 374.45
num::flt2dec::strategy::dragon::bench_big_shortest   3877.01/iter  +/- 45.74
```

`SelfTy` makes it sound like it is literally the `Self` type, whereas in
fact it may be `&Self` or other types. Plus, I want to use the name
`SelfTy` for a new variant of `clean::Type`. Having both causes
resolution conflicts or at least confusion.

Rustdoc often has to special-case `Self` because it is, well, a special
type of generic parameter (although it also behaves as an alias in
concrete impls). Instead of spreading this special-casing throughout the
code base, create a new variant of the `clean::Type` enum that is for
`Self` types.

This is a refactoring that has almost no impact on rustdoc's behavior,
except that `&Self`, `(Self,)`, `&[Self]`, and other similar occurrences
of `Self` no longer link to the wrapping type (reference primitive,
tuple primitive, etc.) as regular generics do. I felt this made more
sense since users would expect `Self` to link to the containing trait or
aliased type (though those are usually expanded), not the primitive that
is wrapping it. For an example of the change, see the docs for
`std::alloc::Allocator::by_ref`.

We already have special-cased code to handle inlining `Self` as the type
or trait it refers to, and this was just causing glitches like the
search `A -> B` yielding blanket `Into` impls.

This is much more readable and idiomatic, and also may help performance
since `match`es usually use switches while `if`s may not.

I also fixed an incorrect comment.

It was barely used, and the places that used it are actually clearer
without it since they were often undoing some of its work. This also
avoids an unnecessary clone of the receiver type and removes a layer of
logical indirection in the code.

`<[T]>::first_chunk` became const stable in 1.77, but `<[T]>::last_chunk` was
left out. This was fixed in 3488679, which reached stable in 1.80,
making `<[T]>::last_chunk` const stable as of that version, but it is
documented as being const stable as 1.77. While this is what should have
happened, the documentation should reflect what actually did happen.

…orks, r=Mark-Simulacrum

std::thread: available_parallelism implementation for vxWorks proposal.

rustdoc: Fix handling of `Self` type in search index and refactor its representation

### Summary

- Add enum variant `clean::Type::SelfTy` and use it instead of `clean::Type::Generic(kw::SelfUpper)`.
- Stop treating `Self` as a generic in the search index.
- Remove struct formerly known as `clean::SelfTy` (constructed as representation of function receiver type). We're better off without it.

### Before

![image](https://github.com/user-attachments/assets/d257bdd8-3a62-4c71-84a5-9c950f2e4f00)

### After

![image](https://github.com/user-attachments/assets/8f6d3f22-92c1-41e3-9ab8-a881b66816c0)

r? ```@notriddle```
cc rust-lang#127589 (comment)

Use `object` in `run-make/symbols-visibility`

This is another case where we can simply use a rust library instead of wrangling nm.

try-job: x86_64-msvc
try-job: i686-msvc
try-job: test-various

…manieu

Remove unnecessary constants from flt2dec dragon

The "dragon" `flt2dec` algorithm uses multi-precision multiplication by (sometimes large) powers of 10. It has precomputed some values to help with these calculations.

BUT:

* There is no need to store powers of 10 and 2 * powers of 10: it is trivial to compute the second from the first.
* We can save a chunk of memory by storing powers of 5 instead of powers of 10 for the large powers (and just shifting as appropriate).
* This also slightly speeds up the routines (by ~1-3%) since the intermediate products are smaller and the shift is cheap.

In this PR, we remove the unnecessary constants and do the necessary adjustments.

Relevant benchmarks before (on my Threadripper 3970X, x86_64-unknown-linux-gnu):

```
num::flt2dec::bench_big_shortest                      137.92/iter   +/- 2.24
num::flt2dec::strategy::dragon::bench_big_exact_12   2135.28/iter  +/- 38.90
num::flt2dec::strategy::dragon::bench_big_exact_3     904.95/iter  +/- 10.58
num::flt2dec::strategy::dragon::bench_big_exact_inf 47230.33/iter +/- 320.84
num::flt2dec::strategy::dragon::bench_big_shortest   3915.05/iter  +/- 51.37
```

and after:

```
num::flt2dec::bench_big_shortest                      137.40/iter   +/- 2.03
num::flt2dec::strategy::dragon::bench_big_exact_12   2101.10/iter  +/- 25.63
num::flt2dec::strategy::dragon::bench_big_exact_3     873.86/iter   +/- 4.20
num::flt2dec::strategy::dragon::bench_big_exact_inf 47468.19/iter +/- 374.45
num::flt2dec::strategy::dragon::bench_big_shortest   3877.01/iter  +/- 45.74
```

run-make: Remove cygpath

Remove cygpath from run-make-support.

Correct the const stabilization of `<[T]>::last_chunk`

`<[T]>::first_chunk` became const stable in 1.77, but `<[T]>::last_chunk` was left out. This was fixed in 3488679, which reached stable in 1.80, making `<[T]>::last_chunk` const stable as of that version, but it is documented as being const stable as 1.77. While this is what should have happened, the documentation should reflect what actually did happen.

…enkov

docs(resolve): more explain about `target`

r? ```````@petrochenkov```````

…rrors

tests: more crashes

r? ``@jieyouxu``