Refactor PHP compatibility and update dependencies for PHP 8.3+

[marcomc]

PHP 8.3+ Compatibility and Dependency Refresh

Summary

This PR makes PHP 8.3 the explicit minimum supported version and refreshes the
runtime/build dependencies needed to keep Workspace quiet and buildable on
current PHP releases.

PHP Requirement and Builders

The Composer PHP constraint is raised from ^8.1 to ^8.3. The local Docker
builders now match that supported range: builder83, builder84, and
builder85 are kept, while the PHP 8.1 and PHP 8.2 builders are removed.

The active release/build path already targets PHP 8.3+, so keeping PHP 8.1/8.2
constraints would make the patch larger and block the dependency updates needed
for newer PHP compatibility.

Symfony Runtime Dependencies

The direct Symfony runtime dependencies now target Symfony 7.4.

Symfony 7.4 supports PHP 8.3 and avoids the PHP 8.4 implicit-nullability
deprecations seen in the previously locked Symfony packages. Symfony 8 is not
used because it would raise the PHP minimum beyond 8.3.

Reflection Access

The branch removes repeated calls to:

$this->properties[$name]->setAccessible(true);

PHP has ignored this call since 8.1, and PHP 8.5 deprecates it. The surrounding
factory style is otherwise unchanged: the code still caches
ReflectionProperty instances and sets values the same way as before.

PHAR Build Tooling

vendor-bin/php-box/composer.json now requires humbug/box ^4.7.

Box 4.7 is compatible with the PHP 8.3 floor and avoids older PHAR build
warnings/failures on newer PHP versions. The deprecated Box metadata setting
is also removed from box.json; Workspace already reports its CLI version from
home/build, so the PHAR metadata is not needed for normal ws version
output.

The explicit bamarni-bin settings preserve the existing isolated Box install
behavior after the plugin upgrade: vendor/bin/box is still created for
tools/scripts/compile.sh, and Composer bin commands keep the current
forwarding behavior.

Development Tooling

Development tooling is refreshed where it does not require a broader migration:

• friendsofphp/php-cs-fixer is updated within the current 3.x line, and the
  mechanical fixes required by the existing config are applied.
  Formatter-only changes were applied in:
  • packages/Console/src/Application/Executor.php
  • packages/Console/src/Application/Plugin/VersionInfoPlugin.php
  • packages/FSM/src/Definition.php
  • packages/FSM/src/Runner/SequenceRunner.php
  • packages/FSM/src/Runner/StepRunner.php
  • packages/FSM/src/State/DefaultState.php
  • packages/FSM/src/Transition/DefinitionTransitionBuilder.php
• phpstan/phpstan is updated within the current 2.x line.
• phpunit/phpunit is updated to 9.6.

PHPUnit is intentionally kept on 9.6 because PHPUnit 11/12 require a separate
migration away from docblock-based tests and non-static data providers. Composer
therefore still reports abandoned Sebastian packages during install; removing
that notice belongs with the PHPUnit migration, not this compatibility patch.

Documentation

The builder list is reduced to the supported PHP 8.3/8.4/8.5 builders,
and the download example now points at the 0.4.x release line
(but it should be updated to the actual future 4.x.x release once that is available).

Compatibility

This branch supports PHP 8.3 and newer:

"php": "^8.3"

That means PHP 8.1 and PHP 8.2 are no longer supported by this branch. The
smallest clean patch under a PHP 8.3 floor is smaller than the earlier
PHP 8.1-compatible variant because it can use newer Symfony, PHPUnit, Box, and
supporting tooling directly.

Known Non-Goals

This PR does not target PHP 8.0, 8.1, or 8.2 compatibility, and it does not
attempt to move to dependency lines that require PHP newer than 8.3.

This PR also does not migrate the test suite to modern PHPUnit attributes.
Composer still reports abandoned Sebastian packages from PHPUnit 9.6 during
composer install; removing that notice requires the PHPUnit 11/12 migration
described above.

Validation

• composer validate --strict
• composer why-not php 8.3.0 --locked
• composer --working-dir=vendor-bin/php-box why-not php 8.3.0 --locked
• php -d memory_limit=1G vendor/bin/phpstan analyse
• vendor/bin/php-cs-fixer fix --dry-run --diff --verbose
• docker compose config
• markdownlint README.md docs/php-compatibility-pr-notes.md
• git diff --check
• builder83: PHP 8.3.31, /app/build.sh, 183 tests / 302 assertions
• builder84: PHP 8.4.21, /app/build.sh, 183 tests / 302 assertions
• builder85: PHP 8.5.6, /app/build.sh, 183 tests / 302 assertions

Box 4.7 reports No warning found. during PHAR compilation on all three
builders, and no PHP deprecation output was observed during the builder runs.

[marcomc]

Thanks for the approval @andytson-inviqa
I see that I have permission to Squash and merge, but I think it's not up to me to decide when this should make it to the 0.4.x branch, I guess it should go with a new patch release (0.4.2?)

[andytson-inviqa]

Thanks for the approval @andytson-inviqa I see that I have permission to Squash and merge, but I think it's not up to me to decide when this should make it to the 0.4.x branch, I guess it should go with a new patch release (0.4.2?)

normally something that's not a bugfix would be a new minor release (so 0.5.0 with a 0.5.x branch target forked from 0.4.x)

deprecation fixes can be bugfix, but the composer changes and min PHP version change I'd be more inclined to new minor release

[marcomc]

so in this case we:

1. branch 0.4.x to 0.5.x
2. update the PR to point to 0.5.x
3. when it's merged we we tag it 0.5.0
4. make the 0.5.0 release

is this the way you have done it before? or have you followed a different approach?
and if that's the path, should I do it? or you or Dave?

[andytson-inviqa]

so in this case we:

1. branch 0.4.x to 0.5.x
2. update the PR to point to 0.5.x
3. when it's merged we we tag it 0.5.0
4. make the 0.5.0 release

is this the way you have done it before? or have you followed a different approach? and if that's the path, should I do it? or you or Dave?

If you have the access needed, you can do it, and yes that's the steps. But also include setting github default branch to 0.5.x for future PRs

The base branch was changed.

[marcomc]

@andytson-inviqa now that I switched the base for the PR it requires a new review.