Make tests pass for people who aren't Colin

[smcv]

• tests: Don't rely on git's default branch name

  The default branch name is configurable via the init.defaultBranch
  configuration option, so we can't count on it being master.
  Explicitly use a non-default branch so that it doesn't matter what
  the default is.

• tests: Don't make assumptions about what will be pushed by default

  What to push by default is configurable via the push.default option,
  so we can't count on it pushing the current branch to the origin
  remote. Explicitly push the branch we're using.

• tests: Configure git to allow file:/// submodules

  Git forbids file:/// for submodules by default, to avoid untrusted
  file:/// repositories being able to break a security boundary
  (CVE-2022-39253). However, this breaks git-evtag's test suite.

  In this test suite, all the repositories are under our control and
  we trust them, so bypass that restriction.

  Bug-Debian: https://bugs.debian.org/1023803

• git-evtag-compute-py: Port to Python 3

  Python 2 reached EOL in January 2020.

• tests: Configure git author/committer name

  Otherwise, recent versions of git will refuse to commit anything on an
  unconfigured system.

  Use Colin's name and email address here for now, rather than a dummy set
  of data. This is because the EVTag covers these, so if we don't use the
  same, we can't possibly get a match for the hard-coded expectation.

  The expectation for the new test added by git-evtag#36 needs to be
  adjusted for this, because it's comparing against a reference that
  was generated using Philip Withnall's name and email address. It seems
  simpler to use the same name and email address throughout the test suite.

• tests: Compare C and Python implementations before making assertions

  It's helpful to be able to see the results of each implementation, and
  whether they agree, before comparing them with the reference.

• tests: Run at build-time

  If we can catch bugs at build-time, then the package doesn't need to be
  included in a distribution so that its as-installed tests can run.

[smcv]

@cgwalters, please could you take a look at this? It's been a while without comment, and I'd really like to be able to run the tests for use in the Debian packaging. I've just updated the PR so tests can still pass with the latest git versions.

I'm not sure how @pwithnall was able to run the test suite for #36, since the first 6 tests expect to be run by Colin (and checks the tags against the expected sha512 for Colin's name and email address), whereas the new test for #36 expects to be run by Philip... but perhaps there's a trick?

[smcv]

If it would be helpful, I can look at adding Github Workflows CI or a less Autotools'y build system as a follow-up to this.

[cgwalters]

Thanks so much for doing this!

[cgwalters]

If it would be helpful, I can look at adding Github Workflows CI or a less Autotools'y build system as a follow-up to this.

That'd be great!

[pwithnall]

This is a victory for people everywhere not called Colin!

[smcv]

If it would be helpful, I can look at adding Github Workflows CI or a less Autotools'y build system as a follow-up to this.

I've done the CI part; please take a look at my other PRs in this repository.

I haven't done a Meson build system yet, but I'll try to come back to that soon. It'll look something like the one in bubblewrap.