Determining whether to create a merge commit would elicit a nested
conditional, which could be hard to parse for a human reader. This is
avoided by returning early as soon as possible for a dry run.

This also resolves the erroneous 'changes committed' message when no
changes were actually committed because of the dry run. A message
specific to dry-run is logged instead.

Existing behaviour is equivalent to force=true, so the default value is
true.

I think the fetch will update the origin/gh-pages branch but not the
gh-pages branch, despite requesting gh-pages. This means that when I
later attempt to rebase the temp branch on top of the gh-pages branch,
there will be nothing to do, because that's already where it is.

I don't expect this to ever require more than one attempt in production,
but in theory it's possible that this procedure could loop forever.

We would need to keep fetching and rebasing if changes keep being added
to the remote. In practice, I believe this would only happen if there
are lots of workflows simultaneously deploying to the same branch, all
using this action. In this case only one would be able to secure a lock
at a time, leading to the total number of attempts being equal to the
number of simultaneous deployments, assuming each deployment makes each
attempt at the exact same time.

The limit may need to be increased or even be configurable, but 3 should
cover most uses.

This test is composed of 3 jobs.

The first two jobs run simultaneously, and as such both depend on the
previous integration test only. The final job cleans up afterwards, and
depends on both of the prior jobs.

The two jobs are identical except that they both create a temporary file
in a different location. This is to ensure that they conflict. Correctly
resolving this conflict by rebasing one deployment over the other,
resulting in a deployment containing both files, indicates a successful
test.