Add workaround for using ipopt with spral as linear solver from Python with libgomp >= 13

[traversaro]

This PR adds a workaround for the issue discussed in https://github.com/conda-forge/casadi-feedstock/issues/93#issuecomment-1732344044 .

In a nutshell, we have the following problems:

• If an executable directly uses the char** environ global variable, then due to copy relocation two different environ symbols are present, one in the executable .bss and one in the glibc .bss . In normal conditions, the one in in the executable .bss is used (for example, this one is the one actually initialized by glibc), while the one in the glibc .bss simply remains initialized to NULL.
• If a shared library is loaded via RTLDDEEPBIND, the environ in the executable is ignored and the environ in the glibc is used, even if it is actually NULL. This is problematic as since gomp 13, during the gomp loading the OMP** variables (that need to be setted for spral to work fine) are accessed via the environ global variable (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556). So, if CasADi is used in an executable that access the environ global variable, spral can't work correctly.
• Apparently, the python interpreter (at least in conda-forge) uses environ directly, so at the moment it is not possible to use spral in casadi python bindings.

To workaround this, I made the following modifications for the casadi's routing to open a library via dlopen([..], [..]|RTLD_DEEPBIND):

• If RTLD_DEEPBIND is used, we first check if we are in the case of a duplicate environ symbol. This is done by calling dlsym(RTLD_NEXT, "environ"), that returns the pointer to the second environ symbol in the process symbol table (as opposed to dlsym(RTLD_GLOBAL, "environ") that just returns &environ). If (char***)dlsym(RTLD_NEXT, "environ") != &environ, then we know that we are in the case of duplicate environ symbol.
• In the case there is a duplicated environ symbol, we set *((char***)dlsym(RTLD_NEXT, "environ")) to the value contained in environ, so that libraries loaded via RTLD_DEEPBIND can access the "real" environ.
• To avoid possible divergences over time of *((char***)dlsym(RTLD_NEXT, "environ")) and environ values, for example due to environ reallocations due to calls to setenv, at the end of the loading we restore *((char***)dlsym(RTLD_NEXT, "environ")) to its original value.

This workaround is working fine locally to fix https://github.com/conda-forge/casadi-feedstock/issues/93, and I also added a regression test in the CI.

Note that in theory this can be problematic if in another thread there is a call to setenv that reallocates (and so invalidates) the value contained in environ. However, this is a risk intrinsic in any access to the environ global variable. For example, if there is a call to setenv after the first loop of https://github.com/gcc-mirror/gcc/blob/15345980633c502f0486a2e40e96224f49134130/libgomp/env.c#L2228, the environ variable could not be valid anymore. So the workaround only have a risk similar to any use of the environ global variable.

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[traversaro]

@conda-forge-admin, please rerender

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [58]

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[traversaro]

@conda-forge/casadi if you have any opinion in favor or against this feel free to comment, thanks!