GH Actions: various improvements to the workflows

[jrfnl]

GH Actions: add ini settings to "release" workflow

Follow-up on PR #65, which turned set error_reporting to E_ALL and turned display_errors on in the Test workflow.

Only just now noticed that I missed doing the same in the Release workflow.

This also changes the setting for error_reporting to -1 as E_ALL does not contain all errors across PHP versions, while -1 will show them, independently of the PHP version.

Also turning on assertions, just in case they are used under the hood in the test framework.

GH Actions: minor simplification

No need for the experimental key, we can just refer directly to the matrix.php version in the continue-on-error condition.

GH Actions: don't run the release workflow on forks

Just in case someone would push a tag up to their own fork.

GH Actions: auto-cancel previous builds for same branch

Previously, in Travis, when the same branch was pushed again and the "Auto cancellation" option on the "Settings" page had been turned on (as it was for most repos), any still running builds for the same branch would be stopped in favour of starting the build for the newly pushed version of the branch.

To enable this behaviour in GH Actions, a concurrency configuration needs to be added to each workflow for which this should applied to.

More than anything, this is a way to be kind to GitHub by not wasting resources which they so kindly provide to us for free.

Refs:

• https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
• https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#concurrency

[grogy]

Why you want stop releasing on forks? Workflow releases into their forks. I don't see problem for resolve

Other commits looks good :-)

[jrfnl]

Why you want stop releasing on forks? Workflow releases into their forks. I don't see problem for resolve

There are two reasons:

1. Oftentimes release workflows contain package specific steps (publishing a GH Pages site for instance) or need access to repo specific secrets. While this is not currently the case for this repo, it still a good safeguard to have in place.
2. More often than not a "release" workflow running in a fork happens by accident, not intentional.
   If a fork would become actively and independently maintained and it is intentional, the maintainer of that fork can adjust the workflow to be applicable to their fork anyway.