Concerns about static vs dynamic TLS in libgomp

I just ran into some very strange errors in https://github.com/conda-forge/staged-recipes/pull/16888
```
tensorflow_addons/metrics/tests/matthews_correlation_coefficient_test.py:21: in
from sklearn.metrics import matthews_corrcoef as sklearn_matthew
../[...]/lib/python3.8/site-packages/sklearn/__init__.py:83: in
from .utils._show_versions import show_versions
../[...]/lib/python3.8/site-packages/sklearn/utils/_show_versions.py:12: in
from ._openmp_helpers import _openmp_parallelism_enabled
E ImportError: dlopen: cannot load any more object with static TLS
```

After some googling, it seems that this is a problem plaguing many users (especially with pytorch/tensorflow). I'm admittedly out of my depths with this, but the [following](https://github.com/pytorch/pytorch/issues/2575#issuecomment-523657178) explanation seemed pretty good:
> As long as PyTorch has a dependency on `libgomp.so` with static TLS, there is _literally nothing we can do_ if some of our users decide to import a bunch of third-party libraries that have dynamic TLS, without importing libgomp. They'll gobble up all of the DTV space and libgomp will fail. Note that we exacerbate the problem by depending on libraries ourselves which have dynamic TLS, so that the ceiling is lower, but if the user imports enough libraries they will hit this problem, no matter how much or little TLS we use.

This has some unfortunate side effects like how changing the import order between libraries [will](https://github.com/scikit-learn/scikit-learn/issues/14485#issuecomment-633452991) [make](https://github.com/pytorch/pytorch/issues/2575#issuecomment-723973114) the error appear / go away. Such kinds of accidents lead to the proliferation of unfortunate (because: randomly working or not) advice of e.g. to uninstall a conda-package and [reinstall](https://github.com/scikit-learn/scikit-learn/issues/14485#issuecomment-761735034) it from pip.

There's [apparently](https://github.com/pytorch/pytorch/issues/2575#issuecomment-523667875) a glibc [fix](https://sourceware.org/git/?p=glibc.git;a=commit;h=f8aeae347377f3dfa8cbadde057adf1827fb1d44) for this since 2015 / glibc 2.22. Unfortunately, not even moving to CentOS 7 (#1436) would help with that, so - coming back to the original quote above - I wanted to ask:

### is it possible for conda-forge to consistently enforce dynamic TLS in libgomp?

Not sure if that's possible or even a good idea, but I wanted to raise this issue so that conda-forge users don't run into such cryptic problems - if there's a way to avoid it.