set custom binary name for frankenphp, allow linking against system openssl (fix mssql issues)

[henderkes]

What does this PR do?

closes #1040

• picked the useful patches from the shared branch
• allows building against system openssl
• sets custom binary name for frankenphp
• reintroduces zig workaround because we use stable zig versions now
• fixes removeConfiguraArgs in UnixAutoConfexecutor

Checklist before merging

If your PR involves the changes mentioned below and completed the action, please tick the corresponding option.
If a modification is not involved, please skip it directly.

• If you modified *.php or *.json, run them locally to ensure your changes are valid:
  • composer cs-fix
  • composer analyse
  • composer test
  • bin/spc dev:sort-config
• If it's an extension or dependency update, please ensure the following:
  • Add your test combination to src/globals/test-extensions.php.
  • If adding new or fixing bugs, add commit message containing extension test or test extensions to trigger full test suite.

[crazywhalecc]

Bypassing check could cause many problems in the future I think. Skipping building and using dynamic libraries should be two separate things, we cannot just do for checking though.

[henderkes]

This behaviour was already intended before, you even documented it: https://github.com/crazywhalecc/static-php-cli/blob/main/docs/en/develop/system-build-tools.md#pkg-config-compilation-nix-only

It was simply bugged before.

[crazywhalecc]

What do you think of it: bin/spc build openssl,curl --build-cli --with-dynamic-libs=openssl (For example, adding a .so definition to the config, or something like shared-pkg-configs)

This allows us to explicitly and definitively determine whether the dynamic library exists and is correctly imported.

[henderkes]

Yes, it's a good idea, but after some consideration, I'm aiming that at v3. For now this is a good enough workaround that implements the logic we already promised.

[crazywhalecc]

Yes, it's a good idea, but after some consideration, I'm aiming that at v3. For now this is a good enough workaround that implements the logic we already promised.

It was simply bugged before.

Yes, although its side effect is linking to system libraries, the system part is beyond our control if we really want to achieve this effect, unless we explicitly specify it and make it clear to ourselves what we want to do.

Passing shared libs explicitly, we could also determine and check lib*.so in SPCConfigUtil, including using system pkg-config.

[henderkes]

That's why this logic only triggers when PKG_CONFIG_PATH is explicitly set. So users will have to e.g. PKG_CONFIG_PATH=/usr/lib64/pkgconfig bin/spc build .... Otherwise, no system libraries are getting linked and we retain the regular static compilation logic.

Passing shared libs explicitly, we could also determine and check lib*.so in SPCConfigUtil, including using system pkg-config.

Generally, yes, I want this to be configurable. It's quite useful for the system packages to minimise disk space, actually. But I don't think we should showhorn it into v2 anymore and then merge it into v3. V3 already gives us better ways to configure and override library compilation logic, so it should be done there directly.