Create tools/release.go to automate release tagging

[aarongable]

Create tools/release.go, a small Go script which automates the creation of release tags.

In its primary mode, it creates a new release tag pointing at the current tip of main. The script assumes that you have "github.com/letsencrypt/boulder" (i.e. this repo) set as your "origin" remote. The new tag is always of the format "v0.YYYYMMDD.0", so that the major version does not make any backwards-compatibility guarantees, the minor version continues our tradition of date-stamping our version numbers, and the patch version can be incremented by hotfix releases. It only pushes the newly-created tag if passed the "-f" flag; otherwise it just creates the new tag locally and exits, allowing the user to inspect it and push it themselves.

In its hotfix mode, it cherry-picks any number of given commits on top of a previously-tagged release, increments the patch portion of the release version number, creates a new tag with the incremented version number, and pushes the resulting tag to the "origin" remote. It also creates (or updates, if one already exists) a corresponding branch whose name is the major and minor portions of the version tag.

This tag naming system is superior to our current "release-YYYY-MM-DD[a]" system for a few reasons. First, by virtue of being a Semver, we get access to tools (like the semver library used in this script, and pkg.go.dev) which understand semver. It shortens our tags, making them easier to read in horizontally-constrained environments like github's tag dropdowns and releases sidebar. And it provides a dedicated place (the patch version) for us to indicate hotfix tags, rather than our ad-hoc letter-based suffix system.

At the current moment, this script has little safety and ergonomics built-in. For example, if one of the cherry-picks fails, it simply quits and dumps the user back into their shell, now likely in git's conflict-resolution mode. Also, because the git cherry-pick command requires that the target ref be checked out, this script changes the user's current branch and does not change it back. However, these can be added over time, as the straight-line logic and familiar Go code make it easy to hack on and improve.

Fixes #5726

[pgporada]

For posterity, I think you can do `// #nosec G204` https://stackoverflow.com/a/75063194

[aarongable]

That works when you're running gosec directly, but not as part of golangci-lint. No, I have no idea why it's different, but I've tripped over it multiple times.

[beautifulentropy]

You've got a failing gomod vendor test.

[aarongable]

Fixed go.mod and resolved merge conflicts.

[pgporada]

Could you add another conditional that shows the operator a basic help menu outside of flag.Parse()? Without this, they'd have to read the code to see that hotfix is an available subcommand.

Suggested change

	if len(os.Args) >= 2 && os.Args[1] == "hotfix" {
	if os.Args[1] == "-h" {
	fmt.Println("go run release.go [hotfix] [args]\n" +
	"-h : display help text")
	} else if len(os.Args) >= 2 && os.Args[1] == "hotfix" {