Increase PHP version requirement to 8.2

[pjcdawkins]

This would need a major version increase.

Backwards compatibility is very important to this project. But this is now a good time for a PHP version requirement increase.

Rationale:

• The newer installation method via the static binary (Go wrapper) has been available for more than a year. This uses its own embedded PHP, currently 8.2 (though it could easily be updated to later versions).
• The legacy installer will continue to work on lower PHP versions, because it filters out incompatible CLI versions.
• PHP 8.1 reached EOL a year ago.
• PHP 7.4 reached EOL three years ago.
• Major PHP frameworks require PHP 8.2, including Symfony, Laravel, and Adobe Commerce. Drupal 10 requires 8.1 and Drupal 11 requires 8.3.
• Metrics on CLI use vary, but in general they show widespread PHP 8.2 and 8.3 adoption (and some PHP 8.4).
• Some CLI dependencies report critical security issues. The issues do not affect this project directly, but others could occur in future. They could only be resolved by upgrading to versions that themselves have PHP >8 requirements, for example Guzzle >5.
• Maintenance and testing by now would be significantly easier without needing to support older PHP versions. For example, public CI images are typically only available with newer versions.

This PR simply updates the PHP requirement. See the (much larger) pull requests #1507 for ugprading Guzzle and #1514 for upgrading Symfony.

[pjcdawkins]

@akalipetis as far as I can see the main blocker here is version numbers, we should probably increase the major version to reflect the backwards compatibility break, but version 5.x has kind of been 'claimed' by the Go CLI. I think the options are:

1. We keep the legacy CLI on 4.x and just increment the minor version (i.e. v4.22.0 requires PHP 5.6 then v4.23.0 requires PHP 8.2). I think this should only practically upset those who are installing it with some very custom method, using neither the Phar system nor Composer (since those both verify the PHP version requirement and restrict upgrade accordingly). However, this feels uncivil, given the significance of the change (PHP 5 to 8, Symfony 3 to 7, 10K lines of code, etc).
2. We keep the version numbers going in an independent, semver way, in both platformsh/cli and platformsh/legacy-cli - which means they'll look similar but confusingly different (e.g. wrapper 5.1.0 embedding legacy 5.0.0).
3. We rewrite the legacy CLI's version number to something completely different, though still quasi-semver, like 100.0.0.