Make releases resilient to failures.

[freakboy3742]

The release of v0.4.3 required 2 passes, because the use of a pre-release freezegun version wasn't picked up as a problem until the toga-core package was pushed to PyPI. However, by this point, toga-android had been successfully published.

As a result of this, any attempt to re-publish toga-android will fail, because the wheel already exists; but there's no way to make any other 0.4.3 artefact complete upload.

This PR modifies the matrix tasks to not fail fast, and continue on error; this would allow a recovery from the 0.4.3 test release.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

The documentation of these settings is a little unclear, but I don't think we want continue-on-error here. That would cause the workflow to always be considered a success regardless of what happens, so if something goes wrong we might not find out for several days.

To ensure we run all jobs in the matrix even if one of them fails, I think fail-fast is sufficient.

Examples:

• https://github.com/orgs/community/discussions/45546
• https://copdips.com/2023/09/github-actions--error-handling.html