Consider not calling dlclose() for extensions

Description

PHP calls dlclose on extension as part of tearing down the runtime. However, dlclose can be really finicky; while I would hope extensions handle it fine (being that they are expected to be loaded and unloaded), the libraries that extensions often depend on often do not, and those can get unloaded as part of collecting garbage by the dynamic linker. If there are any dangling references to things in the unloaded memory, things can be catastrophic.

For example, one issue I've had was with the gnupg extension. It loads libgpg-error as a transitive dependency, and that sets up an atexit handler for clean up. But if the gnupg PHP extension gets unloaded by PHP, the dynamic linker can claim libgpg-error (since it wasn't referenced elsewhere), remove it from memory, and now the dangling atexit handler is all nulls. I have a patch inbound for libgpg-error, but it's one such example.

The problems with dlclose seem known; it was the cause of an OpenSSH exploit a year ago. Platform behaviour with dlclose also seems unpredictable; some platforms have specific criteria that will make them decide to close a library or not, which can be confusing. musl notably turns dlclose into a no-op considering the issues that dlclose brings in.

PHP already has a ZEND_DONT_UNLOAD_MODULES variable used for debugging contexts, since dlclose can confuse i.e. Valgrind. I suspect the main reason to unload modules is embedded SAPIs like i.e. the Apache module, if PHP gets unloaded and reloaded instead of the host going down with it. However, I'm not familiar enough with the embedded SAPIs outside of CLI/CGI to say how common this is.

(This might require an RFC.)

尚未确定任何文件或测试。首先跟踪 dlclose 附近 runtime 的扩展 teardown 路径，并审查 ZEND_DONT_UNLOAD_MODULES 和嵌入式 SAPI 如何影响卸载。确定平台和生命周期要求，然后确定是否需要 RFC；卸载策略和兼容性约束达成一致即表示完成。