CI: switch to GitHub Actions

[jrfnl]

This commit:

• Adds a GH Actions workflow for the CI checks which were previously run on Travis.
• Removes the, now redundant, .travis.yml configuration.
• Updates the .gitattributes file.
• Updates the "Build Status" badge in the Readme to use the results from the GH Actions runs.

Notes:

1. Builds will run on all pushes and on pull requests. Builds can also be manually triggered.
   Note: manual triggering of builds has to be explicitly allowed. This is not a feature which is enabled by default.
2. If a previous GH actions run for the same branch hadn't finished yet when the same branch is pushed again, the previous run will be cancelled.
   In Travis, this was an option on the "Settings" page - "Auto cancellation" -, which was turned on for most, if not all, repos. The concurrency configuration in the GHA script emulates the same behaviour.
3. The default ini settings used by the setup-php action are based on the php.ini-production configuration.
   This means that error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT, display_errors is set to Off and zend.assertions is set to -1 (= do not compile).
   For the purposes of CI, especially for linting and testing code, I'd recommend running with zend.assertions=-1, error_reporting=-1 and display_errors=On to ensure all PHP notices are shown.
   Note: the defaults will be changed in the next major of setup-php to be based on the php.ini-develop configuration, but that may still be a while off.
   Refs:
   • Use php.ini-development by default instead of production one shivammathur/setup-php#450
   • PHP 8.1 / Nightly: update status ? shivammathur/setup-php#469
4. Composer dependency downloads will be cached for faster builds using a predefined GH action specifically created for this purpose.
   The alternative would be to handle the caching manually, which would add three extra steps to the script.
   Note: Caching works differently between Travis and GH Actions.
   On GH Actions, once a cache has been created, it can't be updated. It can only be replaced by a new cache with a different key.
   As the PHP version, the composer.json and a potential composer.lock hash are all part of the key used by the above mentioned action, this difference should not have a significant impact.
   Ref: https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows

Includes adding new builds against PHP 8.0 and 8.1, while transforming nightly to 8.2.

Fixes actions/toolkit#34

[jrfnl]

Current action run results: https://github.com/jrfnl/prophecy-phpunit/actions/runs/1421377047

[jrfnl]

Thanks @stof for working with me on this. I've pulled actions/toolkit#36 and actions/toolkit#37 as next steps - haven't pulled the "widen versions" PR yet as it modifies files also modified in actions/toolkit#36 and actions/toolkit#37, so would lead to conflicts. Will pull that after.