Initial implementation of lazy JLLs for LinearAlgebra

[staticfloat]

This alters CompilerSupportLibraries_jll, OpenBLAS_jll and
libblastrampoline_jll to use LazyLibrary objects and thereby be loaded
only upon first dlopen() or ccall() to the individual library
objects. Note that this is one of the more complicated cases, as
libblastrampoline must have OpenBLAS_jll added as a dynamic dependency
(as it does not actually have it listed in its shared object headers)
and also has some on-load callbacks that must be invoked.

Long-term, I would like to replace the bespoke JLLs here with actual JLL
source code, and vendor a version of LazyJLLWrappers in-tree to do the
actual code generation even for Base. That is left as future work.

[0] JuliaLang/LinearAlgebra.jl#1235

[staticfloat]

This is working locally now, I can confirm that Libdl.dllist() shows that libgfortran, libopenblas64_ and libblastrampoline are all not loaded until the first Linear Algebra call!

Note that this is attempting to conform to the LazyJLLWrappers API, which includes things like eager_mode(), which is called by JLLWrappers.jl. This is to provide backwards-compatibility with JLLs that expect all dependencies from all dependent JLLs to have already dlopen()'ed their libraries.

What this means is that for any realistic workload where there are JLLs that depend on LBT/OpenBLAS, everything is going to get eagerly loaded upon loading of that JLL anyway, until those JLLs are built to use LazyJLLWrappers instead of JLLWrappers, which functionally means waiting for BB2 to be ready, as it contains the new analysis passes that track things like library interdependencies, etc... However, for workloads that never use linear algebra workloads, this will be a nice savings, as the libraries will now never get loaded!

[topolarity]

The --trim failure should be fixed up by #57734

[staticfloat]

I've converted this to draft because I realized that while "real" JLLs that use JLLWrappers will correctly call eager_mode() on these lazy stdlib JLLs, other stdlib JLLs that are not lazy yet but that depend on any of these new lazy stdlib JLLs won't, I need to add that in here.

[topolarity]

It's also worth noting that once we land this PR, --trim will not support loading BLAS until we fix #57707

[topolarity]

I think you might need a rebase for the trimming test to pass, and the following patch:

diff --git i/base/libdl.jl w/base/libdl.jl
index 77f608e77e..d94a2fd0e2 100644
--- i/base/libdl.jl
+++ w/base/libdl.jl
@@ -333,7 +333,7 @@ struct LazyLibraryPath
     pieces::Tuple{Vararg{Any}}
     LazyLibraryPath(pieces...) = new(pieces)
 end
-Base.string(llp::LazyLibraryPath) = joinpath(String[string(p) for p in llp.pieces])
+@inline Base.string(llp::LazyLibraryPath) = joinpath(String[string(p) for p in llp.pieces])
 Base.cconvert(::Type{Cstring}, llp::LazyLibraryPath) = Base.cconvert(Cstring, string(llp))
 # Define `print` so that we can wrap this in a `LazyString`
 Base.print(io::IO, llp::LazyLibraryPath) = print(io, string(llp))

The robust solution to this will require a callable of some kind, but for now massaging is required to make sure that the components of the path are visible to the optimizer