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
```

This is simply a matter of using the right argument for lld-link.

`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.

…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.

…enkov

docs(resolve): more explain about `target`

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

run-make: enable msvc for `link-dedup`

This is just a case of differing style of linker arguments.

I also cleaned up a bit where we were running the same command three times in a row. Instead I reused the output.

One thing that confused me is why we were testing for the same lib three times in a row but not two. After figuring that out I added a note to hopefully save future readers some confusion.

try-job: x86_64-msvc
try-job: i686-msvc

…youxu

Enable msvc for link-args-order

I could not see any reason in rust-lang#70665 why this test needs to specifically use `ld`. Maybe to provide a consistent linker input line? In any case, the test does work for the MSVC linker.

try-job: i686-msvc
try-job: x86_64-msvc

run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`

The common thing between these two tests is to use `#[link(..., kind="static")]` so that it doesn't try to do a DLL import.

`zero-extend-abi-param-passing` also needs to have an optimized static library but there's only helper function for a non-optimized version. Rather than copy/pasting the code (and adding the optimization flag) I reused the same code so that it more easily be kept in sync.

try-job: i686-msvc
try-job: x86_64-msvc

Enable msvc for run-make/rust-lld

This is simply a matter of using the right argument for lld-link.

As a bonus, I also fixed a typo.

try-job: i686-msvc
try-job: x86_64-msvc

…rrors

tests: more crashes

r? `@jieyouxu`