fix: use openssl@3 on macOS, falling back to openssl@1.1

[JamBalaya56562]

Summary

Fix the macOS build failure caused by bin/install hardcoding the
openssl@1.1 Homebrew formula, which Homebrew disabled on 2024-10-24.
Prefer openssl@3 (which PHP 7.4+ supports natively) and only fall back
to openssl@1.1 if it still happens to be installed locally.

Closes #8.

Why

Trying to install any PHP version on a modern macOS goes like this:

$ brew install openssl@1.1
Error: openssl@1.1 has been disabled because it is not supported upstream!
       It was disabled on 2024-10-24.

The homebrew_package_path openssl@1.1 calls in bin/install then
return an empty string, the --with-openssl=$openssl_path flag is never
emitted, and ./configure fails (or builds a PHP without HTTPS support).

openssl@1.1 reached EOL upstream in September 2023 and Homebrew followed
a year later. PHP 7.4 has supported OpenSSL 3 since release 7.4.30, and PHP
8.x supports it fully — openssl@3 is the right default now.

What changed

• New helper homebrew_openssl_path() in bin/install that resolves
  openssl@3 first and falls back to openssl@1.1 if (and only if) the
  user still has it installed for an older PHP branch. Both call sites
  (install_php Darwin block and os_based_configure_options Darwin
  block) now go through it.
• .github/workflows/test-macos.yaml and the macOS section of README.md
  now list openssl@3 in the prerequisite brew install line so the CI
  matrix actually exercises the new path.

The diff in `bin/install`

 homebrew_package_path() {
   ...
 }

+homebrew_openssl_path() {
+  local path=$(homebrew_package_path openssl@3)
+  if [ -z "$path" ]; then
+    path=$(homebrew_package_path openssl@1.1)
+  fi
+  echo "$path"
+}

 install_php() {
   ...
-  local openssl_path=$(homebrew_package_path openssl@1.1)
+  local openssl_path=$(homebrew_openssl_path)
   ...
 }

 os_based_configure_options() {
   ...
-  local openssl_path=$(homebrew_package_path openssl@1.1)
+  local openssl_path=$(homebrew_openssl_path)
   ...
 }

Compatibility notes

• PHP 8.x — fully supports OpenSSL 3, no caveats.
• PHP 7.4 — supported OpenSSL 3 from 7.4.30 onward. Earlier 7.4.x
  patch releases will still build but emit deprecation warnings during
  make. Users on those patches typically already have openssl@1.1
  cached locally, in which case the fallback kicks in.
• PHP 7.0 – 7.3, PHP 5.x — required OpenSSL 1.1. Users targeting
  these need to install openssl@1.1 from a third-party tap (e.g.
  homebrew/cask-versions or a community formula) and the fallback
  resolves to it. Without it, --with-openssl is omitted and PHP
  builds without HTTPS support, same as the current behaviour.

The fallback ordering is important: we always prefer @3 because that's
what most users want, and @1.1 only wins when the user explicitly
installed it for a legacy build.

Out of scope

• Removing openssl@1.1 support entirely — kept as a fallback so legacy
  PHP installs that the user has already configured don't regress.
• Linux/Windows OpenSSL handling — different mechanism, not affected by
  this Homebrew change.

[aooohan]

Thank you for identifying the Homebrew OpenSSL issue and proposing a fix. This is now addressed by #24 and released in v0.3.1.

The shipped implementation selects the dependency by PHP version: PHP 8.1+ uses OpenSSL 3, while older versions select the legacy dependency and report a clear error when it is unavailable. Explicit PHP_CONFIGURE_OPTIONS are preserved. The README and macOS CI prerequisites were also updated, and the complete macOS installation check passed.

We cannot use the unconditional OpenSSL 3 preference from this PR for all versions: the official PHP requirements specify OpenSSL < 3.0 for PHP 7.1–8.0, so the stated PHP 7.4 compatibility would be unsafe to rely on.

Closing as superseded by the version-aware fix in #24. Thank you for the contribution.