…to preserve all UB that the native intrinsic would have

…nton

Reduce code size of `thread::set_current`

rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.

…ChrisDenton

Move thread parking to `sys::sync`

Part of rust-lang#117276.

I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.

r? `@ChrisDenton` (if you have time)

…dy, r=RalfJung

Let miri and const eval execute intrinsics' fallback bodies

fixes rust-lang/miri#3397

r? `@RalfJung`

…, r=Mark-Simulacrum

lldb-formatters: Use StdSliceSyntheticProvider for &str

&str has associated summary provider which correctly displays string values in debugger, but while working on rust-lang#124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging

However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value

I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
    frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
   44  	    let plain_str = "Hello";
   45  	    let str_in_struct = Foo { inner: "Hello" };
   46  	    let str_in_tuple = ("Hello", "World");
-> 47  	    zzz(); // #break
   48  	}
   49
   50  	fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
  vec = size=5 {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
(&str) plain_str = "Hello" {
  data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
  length = 5
}
(strings_and_strs::Foo) str_in_struct = {
  inner = "Hello" {
    data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
}
((&str, &str)) str_in_tuple = {
  0 = "Hello" {
    data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
  1 = "World" {
    data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
}
```
After this PR it would look the following way:

```
* thread #1, name = 'a', stop reason = breakpoint 1.1
    frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
   44  	    let plain_str = "Hello";
   45  	    let str_in_struct = Foo { inner: "Hello" };
   46  	    let str_in_tuple = ("Hello", "World");
-> 47  	    zzz(); // #break
   48  	}
   49
   50  	fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
  vec = size=5 {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
(&str) plain_str = "Hello" {
  [0] = 'H'
  [1] = 'e'
  [2] = 'l'
  [3] = 'l'
  [4] = 'o'
}
(strings_and_strs::Foo) str_in_struct = {
  inner = "Hello" {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
((&str, &str)) str_in_tuple = {
  0 = "Hello" {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
  1 = "World" {
    [0] = 'W'
    [1] = 'o'
    [2] = 'r'
    [3] = 'l'
    [4] = 'd'
  }
}
```

…r, r=tmandry

Set non-leaf frame pointers on Fuchsia targets

This is part of our work to enable shadow call stack sanitization on Fuchsia, see [this Fuchsia issue](https://g-issues.fuchsia.dev/issues/327643884).

r? `@tmandry`

…pointer-coercion-happens, r=compiler-errors

We do not coerce `&mut &mut T -> *mut mut T`

Resolves rust-lang#34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?