... use `ubuntu-18.04` or `ubuntu-latest` for `20.04` instead.

Also see:
* https://ubuntu.com/blog/ubuntu-16-04-lts-transitions-to-extended-security-maintenance-esm
* shivammathur/setup-php#452

As no code coverage is being recorded for these builds, it is good practice to explicitly set `coverage: none` in `setup-php`.
This fixes a warning on PHP 5.3 stating that Xdebug is on.

... by using the `ramsey/composer-install` action.

This means that the Composer downloads directory for dependencies will be cached and restored on each build. This conserves resources and should also make builds faster.

Ref: https://github.com/marketplace/actions/install-composer-dependencies

Psalm does not need to be run against multiple PHP versions. Running it once should be enough.

With that in mind, this commit:
* Introduces a separate, dedicated workflow which only installs and runs Psalm.
* Removes the Psalm related steps from the `CI` workflow.
* Removes Psalm from the `tools` setting for `setup-php`.

While the builds currently all show "green", if you actually fold out the "PHPUnit Tests" step, you can see that the tests haven't actually been running on PHP 5.3, 5.4, 5.5, 5.6.

As of PHP 7.0, they have been running, but running against a mismatched PHPUnit version as all test runs are run against PHPUnit 9.5.x, while PHPUnit 9.5 is officially only supported on PHP 7.3 and higher.

Additionally, PHPUnit was being installed 3 (!) times, once via the `setup-php` action, once via the `composer install` and once via the `php-actions/phpunit` action.

To ensure that the tests are always run against the most appropriate PHPUnit version for the PHP version against which the tests are being run, I propose to:
* Remove the installing of PHPUnit via `setup-php`.
* Remove the use of the `php-actions/phpunit` action.
* Defer to the Composer installed PHPUnit version in all cases.

I'm also removing the explicit ini settings for the "moderate" and "modern" jobs.
These look like they were copied over from example code, but these values don't have any effect on the test runs in these workflows, so may as well be removed.

For the "low" job, however, having some ini values set prevents the tests erroring out too quickly.

As there is now effectively no difference anymore between the `moderate` and `modern` jobs, these jobs can now be merged into one.

The default setting for `error_reporting` used by the SetupPHP action is `error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT` and `display_errors` is set to `Off`.

For the purposes of CI, I'd recommend running with `E_ALL` and `display_errors=On` to ensure **all** PHP notices are shown.

Ref: shivammathur/setup-php#469

For now, this build is still allowed to fail.

I'd like to suggest adding this as a temporary measure until the failing code has been fixed.

The `fail-fast` setting defaults to `true` and has the effect of cancelling any and all running/waiting builds within the same workflow as soon as one build has failed.

By setting this to `false`, all builds will be always be run, allowing for easier debugging of the current test failures.