Support PHP 8.5

[sukhwinder33445]

The following packages do not yet provide support for PHP 8.4/8.5:

• shardj/zf1-future
• erusev/parsedown (replaced with parsedown/parsedown)

require: #87

[sukhwinder33445]

I have cleaned up the commits. The WIP commits must be removed before merging this branch.

[sukhwinder33445]

Package react/promise has been upgraded to latest version 3.3.0.

[Al2Klimov]

For some reason, the PR breaks Director again, see #82 (review).

Moreover, I couldn't even cross-check it with own release/snapshot packages without modifying it:

• git checkout 08d05d0
• bin/make-release.sh 0.15.0 --no-tag # Says: ERROR: Composer validate failed

I had to comment out the "Composer validate failed" line in bin/make-release.sh:

• git checkout 08d05d0
• perl -pi -e 'if (/Composer validate failed/) { s/^/#/ }' bin/make-release.sh
• bin/make-release.sh 0.15.0 --no-tag
• git tag v0.15.0

... so that I can test actual packages:

• git remote add fork git@github.com:Al2Klimov/icinga-php-thirdparty.git
• git push fork v0.15.0
• git tag -d v0.15.0
• git checkout .
• git checkout -
• git branch -D stable/0.15.0

[Al2Klimov]

My last review still applies. Either fix that or do this:

--- a/bin/make-release.sh
+++ b/bin/make-release.sh
@@ -42 +42 @@ git commit -m "Version v$VERSION"
-composer validate --no-check-all --strict || fail "Composer validate failed"
+composer validate --no-check-all || fail "Composer validate failed"

[Al2Klimov]

* I mean not (necessarily) now, but before merging this PR.

My point is just, if we merge it as-is, both snapshots and releases would break. As discussed with @lippserd offline, that's exactly what we won't do. Instead, we must make a decision (one nice day? CW45?) what we do with this:

[fedora@aklimov-fedora icinga-php-thirdparty]$ composer validate --no-check-all --strict
./composer.json is valid, but with a few warnings
See https://getcomposer.org/doc/04-schema.md for details on the schema
# General warnings
- The package "erusev/parsedown" is pointing to a commit-ref, this is bad practice and can cause unforeseen issues.
- The package "shardj/zf1-future" is pointing to a commit-ref, this is bad practice and can cause unforeseen issues.
[fedora@aklimov-fedora icinga-php-thirdparty]$ echo $?
1
[fedora@aklimov-fedora icinga-php-thirdparty]$

Either, if we need those commit-refs in the long run, we remove --strict – but that's not the preferred option. Ideally those ref-ed commits get upstreamed and we won't need commit-ref anymore.