(cherry picked from commit ef511c9)

* Consistently use `RUNPATH` in our libraries

When loading dependencies on Linux, we can either use `RPATH` or
`RUNPATH` as a list of relative paths to search for libraries.  The
difference, for our purposes, mainly lies within how this interacts with
`LD_LIBRARY_PATH`: `RPATH` is searched first, then `LD_LIBRARY_PATH`,
then `RUNPATH`.  So by using `RUNPATH` here, we are explicitly allowing
ourselves to be overridden by `LD_LIBRARY_PATH`.  This is fine, as long
as we are consistent across our entire library line, however in the
`v1.8.0` release, there was an inconsistency, reported in [0].

The inconsistency occured because of the following confluence of factors:

 - Ancient `ld` builds (such as the one used in our build environment)
   do not default to using `RUNPATH`, but instead use `RPATH`.
 - `patchelf`, when it rewrites the RPATH, will default to using
   `RUNPATH` instead.
 - We were only using `patchelf` on `libjulia-internal`, not on
   `libjulia-codegen`, which was newly added in `v1.8`.

These three factors together caused us to ship a binary with `RUNPATH`
in `libjulia-internal`, but `RPATH` in `libjulia-codegen`, which caused
loading to fail in [0] due to first `libjulia-internal` being loaded,
(which brought in the external `libstdc++`), then `libjulia-codegen`
failed to load (because it found an incompatible `libstdc++`), causing
the mysterious compiler error.

This PR fixes this twofold; first, when building the libraries in the
first place, we pass `--enable-new-dtags` to the linker to encourage it
to use `runpath` when possible.  This removes the possibility for a
missing `patchelf` invocation to break things in this way.  Second, we
apply `patchelf` properly to `libjulia-codegen` as well.

[0] #46409

* fix whitespace

Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>

* [Makefile] Fix codesign of libjulia when installing it on macOS

* Add shell sript for codesigning and use it in Makefile

(cherry picked from commit 8076517)

(cherry picked from commit c65e56f)

(cherry picked from commit 70656e2)

…#46375)

By looking up keys, we possibly grow the hash table, invalidating the iteration
we were doing in jl_collect_backedges. First perform a non-mutating check instead,
and assert that the hashtable doesn't change during iteration.

(cherry picked from commit 0ada892)

… tries a new Union decision (#46350)

* `intersect_all` should always `restore_env`. let `merge_env` track valid `env` change.

* Add test.

Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
(cherry picked from commit 9aabb4c)

(cherry picked from commit e0056c8)

(cherry picked from commit 99e8953)

(cherry picked from commit 947c908)

(cherry picked from commit c3d5009)

also remove a bunch of `@inline` from when I didn't trust the compiler to do reasonable things.

(cherry picked from commit 445586d)

(cherry picked from commit fd66c30)

Turns out when you declare an alloca alignment, it also rounds up
the allocated size. Replaces #46322 and #46260 and fixes the
same issue.

(cherry picked from commit e358a17)

(cherry picked from commit c491e79)

Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
(cherry picked from commit 3b81696)

…s do not overlap. (#45578)

* Fix union!(s::BitSet, r::AbstractUnitRange{<:Integer}) when two ranges do not overlap.
Resizing of BitSet should be filled with 0 by default.

(cherry picked from commit 5e8e0a5)

`CachedMethodTable` was removed within #44240 as we couldn't confirm any
performance improvement then. However it turns out the optimization was
critical in some real world cases (e.g. #46492), so this commit revives
the mechanism with the following tweaks that should make it more effective:
- create method table cache per inference (rather than per local
  inference on a function call as on the previous implementation)
- only use cache mechanism for abstract types (since we already cache
  lookup result at the next level as for concrete types)

As a result, the following snippet reported at #46492 recovers the
compilation performance:
```julia
using ControlSystems
a_2 = [-5 -3; 2 -9]
C_212 = ss(a_2, [1; 2], [1 0; 0 1], [0; 0])
@time norm(C_212)
```

> on master
```
julia> @time norm(C_212)
364.489044 seconds (724.44 M allocations: 92.524 GiB, 6.01% gc time, 100.00% compilation time)
0.5345224838248489
```

> on this commit
```
julia> @time norm(C_212)
 26.539016 seconds (62.09 M allocations: 5.537 GiB, 5.55% gc time, 100.00% compilation time)
0.5345224838248489
```

(cherry picked from commit 8445744)

(cherry picked from commit ce6e9ee)

(cherry picked from commit 98e1b13)

(cherry picked from commit b64743b)

The docs on multithreading still warns that the default scheduler for @threads
uses static scheduling. However, since #44136, dynamic scheduling has been the
default. This commit removes the warning.

(cherry picked from commit 72222d6)

(cherry picked from commit 5c5af1f)

(cherry picked from commit 431071b)

(cherry picked from commit 1fae1b9)

(cherry picked from commit 99340fe)

(cherry picked from commit 1715110)

* Make `Fix1(f, Int)` inference-stable
* split `_xfadjoint` into `_xfadjoint_unwrap` and `_xfadjoint_wrap`
* Improve `(c::ComposedFunction)(x...)`'s inferability
* and fuse it in `Base._xfadjoint`.
* define a `Typeof` operator that will partly work around internal type-system bugs

Closes #45715

(cherry picked from commit d58289c)

(cherry picked from commit c2a1650)

* fix invalidations in REPL LineEdit.jl from Static.jl

(cherry picked from commit 99d8c7b)

This is a follow-up to #46481. I suggest the labels `latency` and `backport-1.8`.

(cherry picked from commit f1f5d59)