Start publishing versioned + tagged GitHub releases

[cpu]

I propose we use a model of semver based roughly on the Rust/cargo definition, especially in the early stages of the process as we gather more experience.

This guide uses the terms “major” and “minor” assuming this relates to a “1.0.0” release or later. Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

Concretely, we would start with a v0.0.1, and reserve the right to make breaking changes between v0.0.1 and v0.0.2, continuing in this fashion until we've gained enough confidence to consider a stricter regiment. The emphasis of this project is test data, and so I think we can allow ourselves more liberty to evolve than other contexts may permit. The community management model is also new, and so we should try not to lock ourselves in to the existing structure too soon while topics like https://github.com/C2SP/wycheproof/issues/167 are in the air.

For each release I propose we push a git tag, and create a GitHub release with some manner of manually curated changelog, highlighting new additions, bug fixes, and breaking changes.