BREAKING: Increment root package version based on release specification

[Mrtenz]

Before this change, the new version of the root package is always incremented by one (or minor one, for backports). This results in all releases being "major" releases, even though the packages incremented in the release could be minor or patch increments. With this change, the root package version is now determined by the most significant subpackage increment. For example, if all packages versions are patch increments, the root package version will be incremented with a patch increment, etc.

Breaking changes

• This removes the backport option, as it's no longer used for anything.

[mcmire]

@Mrtenz Hmm. We've been creating backports for various libraries lately, so although that hasn't happened for core yet, I hesitate to remove that feature from this tool.

A little context: When we revised the release process for the core monorepo, we decided that the release version wouldn't abide by SemVer (I don't have the discussion handy, but I can find it). Why? Because the monorepo isn't a public package. The only place that the monorepo release version shows up is release notes, but no one needs to use it explicitly. It's just a way of naming the release. We discussed using a date instead of a version string as a name, but then if we wanted to name a backport release, we wouldn't have a good way of doing that. Repurposing the version string seemed to satisfy our need at the time.

I understand if this might be confusing, though. I'm open to other alternatives, as long as there's still some way to denote a backport. What are your thoughts?