Incompatible shared libraries when called from other process (Linux)

When a compiled julia binary is called from another process that has already loaded libstdc++.so.6, then the already loaded version is also used for the julia process. If the version of libstdc++ is incompatible this leads to crashes.

One frequently occurring example is calling a compiled julia binary from an older version of MATLAB (via the MATLAB system() command).
Error: `libstdc++.so.6: version GLIBCXX_3.4.29 not found`
A solution is to run the following line before opening MATLAB to force the newer libstc++:
`export LD_PRELOAD=//lib/julia/libstc++.so`

With matlab version 2022b, there is another issue of incompatible libunwind.so, leading to a segmentation fault of the julia process, when called from matlab.
`export LD_PRELOAD=//lib/julia/libunwind.so`
fixes this

However, in certain cases it is not possible to adjust the shared library version of the calling program.

There seems to be a way to compile julia without the dependency on libstdc++.so. I think this would be a good feature to add as option in PackageCompiler.jl, increasing the portability of compiled code.

Start by investigating how PackageCompiler.jl builds compiled binaries and how their shared-library dependencies are selected. Reproduce the libstdc++ or libunwind conflict when a compiled Julia binary is launched from MATLAB or another process. Done means a documented option can produce binaries without the incompatible dependency, with portability verified in the described scenario.

Written by the indexing model from the issue text.