feat: use GraphQL when possible, fall back to REST if necessary

[avidal]

Prior to v3, commit-headless always used the GraphQL API to create commits. It's a single API call that replaces 3+ calls via the REST API (create blob for each file, create a tree, then create the commit).

However, the GraphQL API had some limitations:

• File modes are not preserved. Pushing a commit that updates a symlink or an executable file would result in the mode being reset to 100644 (plain file)
• No ability to force push: you must always specify the expected head SHA and not having the correct head SHA would fail the commit

So in v3 I swapped to the REST API. It's more API calls, sure, but it's more flexible. It allowed me to introduce new functionality, such as:

• The replay command to replace an unsigned remote commit with a signed one
• Force pushing for cases where you may rebase in your workflow

However, this uncovered another issue: commits created via the REST API using user tokens are not signed (server/app tokens are signed). Since we have some use cases where a system is acting on behalf of a user, this was a significant regression.

To address the issues with the REST API and the issues with the GraphQL API, this patch implements a hybrid approach:

• Use the GraphQL API by default: less API calls means less likely to hit rate limits
• Swap to the REST API if a commit contains a file with a non-standard file mode

To address the issue with force pushes all commits are created on a temporary branch, branched off of the supplied --head-sha. Once all commits are created, regardless of strategy, the REST API is used to update the reference on the supplied target branch to point to the HEAD of the temporary branch and the temporary branch is discarded.

You can think about this workflow as analogous to working on a "feature branch" and then fast-forward merging the feature branch.

For force pushes or replays, it's analogous to first resetting the target branch to an earlier commit and then fast forward merging the temporary branch.

This has the secondary benefits of all work being done in a staging area (the temporary branch). The target branch is left alone until the very end.

Note there is one caveat: because signing is more important than file mode preservation, if a user token is detected, all commits will be created using GraphQL.