Better "study repo" init and upgrade paths

[sebbacon]

What I want:

• A new user types opensafely init to create a new, empty study repo
• An existing user types opensafely upgrade to upgrade an existing study repo to support a new version

The former is easy and close to what we already do; we should probably use cookiecutter to do it. The latter is harder. What does "upgrade" mean? I think it's two major food groups:

1. Introducing a new version of cohortextractor that has breaking changes, for example:

• Changes in study definition function signatures
• The new requirement that a project.yaml must exist

2. Introducing new working practices, for example:

• Every repo must have a LICENSE.txt
• CI via GHA changes (e.g. using Releases more consistently)

In the case of (1), we need to be able to pin versions of (i) the project.yaml format and (ii) the study definition API. Currently these are versioned with separate version numbers. We could version them with the same token. This has the advantage of simplicity (e.g. all the documentation can be versioned to the same token). I can't think of a disadvantage to this, in fact...

Then, when someone runs opensafely upgrade, this means:

• Fetching the most recent version number
• If it's a minor version change, update the version number in project.yaml and pip install the latest cohortextractor package. Probably also start to make use of deprecation warnings, and print those
• If it's a major version change, print a list of breaking changes and prompt the user to confirm if they want to complete the upgrade

For (2), the upgrade script should just have a set of changes that should be applied somehow. Perhaps it's a migrations/ folder in the cohortextractor repo which contains files named for version number 1_3_7_add_license_txt.py which are executed in order from the source to the destination version?

Are there existing packages which make this kind of thing easier? It feels like it should be trivial enough not to worry about that, but maybe I've not thought it through carefully enough

[sebbacon]

Closed for related issue in opensafely-cli repo