Build infrastructure refresh

[bwhmather]

Planning ticket for discussing potential changes to our build system.

Follow on from discussion in #79, #81 and #86

[bwhmather]

Thank you @cghar for prompting this. After some deliberation, I think I have some idea of what we should be aiming to achieve.

What I think should be our particular priorities for any build infrastructure:

1. We want to run our tests using all supported versions of python at every stage of development - SSort, by its nature, is very sensitive to changes in the python language and requires version specific logic to match every new release.
2. We want the process for getting setup to make changes to be as straightforward as possible - SSort development is fairly slow and gentle so most development isn't started from a fresh setup. Existing developers will often have gone through OS releases that break binary compatibility, and new developers from a fresh checkout.
3. We don't want the CI release step to break ever - Fixing release failures tends to involve lots of hacking about and force pushing to master. Messing with master breaks the link between PyPi and git and the pretence that we are a process driven project.

What I think we should be prepared to sacrifice:

1. We don't need to be running the latest version of any of our dev dependencies - Bugs in old versions of lint tools are unlikely to be a security issue, but backdoors in new versions very definitely are.
2. We don't need our tests to run more quickly - It's unlikely that our test suite will be run more than a hundred times a year. A clean tox run on my fanless dual core handbag laptop takes 1 minute, 18 seconds and that is fine.

[bwhmather]

If we are to tackle this incrementally (i.e. keeping tox and the current github actions setup), then I think there are really three things we should be focusing on:

1. We should work to pin as many of our dev dependencies as possible.
2. We should carefully review any dependencies that we can't pin and make sure that we only depend on stable and supported interfaces.
3. We should try to figure out how to test our release process.

[bwhmather]

If we are to replace tox then I would expect the replacement to also meet the following requirements:

1. It must be possible to install from the repositories of most major linux distributions. Having to pip install globally or in a virtualenv is unacceptable.
2. It must be able to orchestrate running the test suite using every supported version of python.
3. It must have demonstrated a commitment to backwards compatibility. A reasonable threshold might be that a build script written for the versions available at the start of this project (2021) should still run today.

Additionally, it any replacement should probably bring something a bit extra, for example:

1. It might make it easier to keep in sync with our CI setup.
2. It might support downloading and installing a sandboxed snapshot of every supported version of python.

[bwhmather]

Sorry, that's a bit more of an essay than I had originally planned but hopefully it works as a starting point.