Support PHP 8.4 and work around reporting implicitly nullable types

[clue]

This changeset adds support for PHP 8.4 and works around reporting any implicitly nullable types. This is part 10 of reviving Ratchet as discussed in #1054, unblocking more future progress.

With these changes applied, the existing test suite recently updated with #1097, #1096, #1094, #1093 and #1092 now works fine on PHP 8.4 at last. Once merged, this would conclude the recent PHP version improvements, but there's still more than enough work to be done to clean up the project as suggested in #1054 and elsewhere.

Note that this employs a number of workarounds to avoid raising deprecation notices for implicitly nullable types as discussed in reactphp/promise#260 and related tickets. In particular, we can't use proper nullable types like ?LoopInterface here without introducing a massive BC break because this requires PHP 7.1+ while this project still supports ancient PHP 5.4+, see #1003 and others. I've applied some clever workarounds originally suggested in reactphp/stream#179 plus clue/framework-x#225 / https://x.com/another_clue/status/1671189006162464768 / https://github.com/reactphp/promise/pull/246/files#r1235943582. I think it's easy to argue this is either hilarious or disgusting (YMMV). While I agree this isn't exactly perfect, I think it's good enough to get this working on newer PHP versions again without applying a major refactoring and introducing any BC breaks. Future PRs to improve this very much welcome.

Overall, this required quite a massive effort. If you want to support this project, please consider sponsoring @reactphp ❤️

Builds on top of #1097, #1096, #1094, #1093, #1092, #1091 and #1088, one step closer to reviving Ratchet as discussed in #1054
Resolves / closes #1003

[PaulRotmann]

👍

[clue]

For the reference: I understand this looks a whole lot like a BC break, but I don't think it qualifies as one. While this certainly looks nasty, I think this should be fully backward compatible across all supported PHP versions.

The comment has the effect that PHP 8 sees this definition public function onOpen(ConnectionInterface $conn, ?RequestInterface $request = null) while legacy PHP < 8 would see the definition public function onOpen(ConnectionInterface $conn, RequestInterface $request = null). Note that the only difference here is the ?RequestInterface $request = null vs RequestInterface $request = null.

For all supported PHP versions, you would determine the parameter to be nullable, no matter if the ? is present or not:

• For legacy PHP < 7.1, the former would be a syntax error, so only the latter definition applies.
• For PHP 7.1 - PHP 8.3 this wouldn't make a difference at all. For PHP < 8 we apply the former definition, for PHP 8+ the latter, but either would be ok really.
• For PHP 8.4+, they would still apply the exact same logic, but the former would be the recommended way, while the latter would report a deprecation notice.

Thanks to the nasty comment hack, PHP 8.4+ would never interpret the second line, so no deprecation would be triggered in any PHP version.

(If you want to learn more about how the hack works, follow the links above, e.g. https://x.com/another_clue/status/1671189006162464768)

[clue]

Alright, let's get this shipped so more people get to use this!