Add (initial) support for PHP 8.4

[jnoordsij]

This MR:

• Runs the testsuite against PHP 8.4 (uses the currently still unstable beta version); to allow this the --ignore-platform-req=php+ is added to composer calls in integration tests, to ignore checking package bounds on upper PHP versions
• Replaces deprecated implicit nullable types in parameter declarations (see https://wiki.php.net/rfc/deprecate-implicitly-nullable-types) see Replace implicit nullable types in parameter declarations #1632

To make (integration) tests pass, the following changes are introduced:

• As Laravel cannot install yet by default with PHP 8.4, per Tag for PHP 8.4 support nette/schema#68, the suggestion there is applied to ignore PHP version in platform req checks for composer. Although opting to wait for a fix of the mentioned issue is also viable, I think not checking PHP version (through composer) for integration tests is a reasonable change, as any impactful change should already be breaking the tests anyways, and still end-users will be warned when installing with composer.
• The integration test is somewhat altered, as previously it checked for an empty logs directory. Due to deprecations in previous Laravel/Lumen versions being triggered on PHP 8.4, a log file is created by Laravel to log these messages. This MR changes the integration test to solely test functionality of the clear command, by adding a test file to the directory that should be cleared and subequently testing emptiness of that directory.

[jnoordsij]

Marked as draft as PHP 8.4 for tests might be just a little too early. The deprecation fixes were moved to #1632 so they can be merged already.

[jnoordsij]

@barryvdh I've slightly reworked integration tests to make sure everything passes, LMK what you think!

[barryvdh]

Why do we need to ignore the platform reqs?

[jnoordsij]

As long as nette/schema does not tag 8.4 compatible (see nette/schema#68), composer won't install Laravel on 8.4+.

[barryvdh]

I think it's tagged now, can we remove the platform reqs skipping?

[barryvdh]

What is this change exactly?

[jnoordsij]

I'm not exactly sure on what the intended check was doing. This check was introduced with #1118 and seems to aim to check for 'succesful completion' of the php artisan debugbar:clear command on a fresh Laravel installation. Here 'succesful' seems to be measured by "not logging any messages" (and not exiting with non-zero code).

However, this metric seems slightly off to me. In this case it was erring, because (due to maximebf/php-debugbar#687) deprecations are being logged while running the command. There are ways to work around this, e.g. suppressing deprecations with some Laravel flag.

I've here opted to rather than trying to patch the old definition of 'succes', come up with a new one that actually feature-tests the actual command. Given that the purpose of the command is cleaning json files from the storage/debugbar directory, I've now added a check to ensure the command does just this. Thus the new definition of 'succesful' is now the combination of php artisan debugbar:clear exits with code 0 and does feature-wise what it's expected to do.

[jnoordsij]

I think it's tagged now, can we remove the platform reqs skipping?

Just rebased and removed the commit, although I'd still argue it might've been beneficial to have for testing either way.