[Kinflou]

The CLI half of ComlineProject/core#133 (core#122 / cli#82, decided in docs#64).

• comline release builds first, so what's released is what's in src/, then creates the version from the highest bump since the last release. It prints the changes behind it, the bump, and any reason. If nothing calls for a bump, it refuses unless the bump is raised.

• --raise patch|minor|major --reason "…" releases a higher bump. The reason is required and recorded. Raising to major asks first. A raise the changes already reach is reported as covered.

• comline release 1.0 says what 1.0 commits to:

  • from then on a breaking change is a major release;
  • the package's protocols and their handshakes;
  • things worth settling first, for information only: given-up guarantees and deprecated declarations.

  Then it asks. Any other version is refused, because versions come from the changes.

• Confirmation follows comline accept's pattern: ask on a terminal (default no); otherwise exit 2 unless --yes.

• comline build reports initial build 0.1.0-dev.1 and a next release: 0.1.1 (new features since 0.1.0) — run comline release`` line.

• package_versions = "all" now generates every release, not every build. A list can still name builds.

Not here, by decision: --lower (its consumer acceptance isn't designed) and assigning @id at 1.0 (core#127). build --release stays the reserved no-op it was; its name now reads oddly beside comline release, so it's worth a decision whether to drop it.

Tests:

• tests/cli/release.rs covers releasing, nothing to release, raising (reason, confirmation, covered), and 1.0 (refused without confirmation, then once only, and release 2.0 refused).
• The existing tests use the new versions, and the multi-version generate tests now release twice.
• I drove the 1.0 prompt by hand through a pseudo-terminal: n releases nothing, y releases 1.0.0.

113 tests pass. Merge after the core PR and generation.