Fixup reference-transaction hook name based on arguments

While the reference-transaction hook was released with Git v2.28.0, it's got a bug which will cause Git to accidentally execute the wrong hook if there's been interleaving calls to both the reference-transaction and another hook. This bug currently prohibits us to use the hook for reference transaction voting until a new Git version is released with the upstreamed fix. Given that this could be as late as release v2.29.0, it's potentially still quite a while until we can use the hook.

As a temporary workaround, we may manually fixup hook names in our gitaly-hooks binary. GitLab systems only have at most four hooks installed: reference-transaction, pre-receive, update and post-receive. Because of how these hooks get called, we should be able to tell the case when Git meant to execute the reference-transaction hook instead of any of the other three by inspecting the hook's arguments:

- reference-transaction will receive as first arguments one of
  prepared, committed or aborted

- pre-receive never gets any arguments

- update will get as first argument the reference that is to be
  updated in its fully-qualified form (e.g. refs/heads/master) and
  thus should never clash with any of the three above verbs

- post-receive never gets any arguments

So none of these hooks except for the reference-transaction hook will ever get executed with one of prepared, committed or aborted. If they were executed with such an argument, we can be sure that Git wanted to execute the reference-transaction hook instead.

So let's work around the bug by mangling arguments in case we're called as a hook with exactly a sinlge argument which is either "prepared", "committed" or "aborted".