Name the vote-passed versions explicitly; never take them positionally (#822)

`vote-passed <old_version>` published the version resolved from the tag and
deleted the version passed as the argument. Two versions that do opposite things,
and only one of them positional - the deleted one. Reading `vote-passed 9.7.0` as
"release 9.7.0" is the natural interpretation, and it would have promoted 9.7.0
into dist/release and then immediately svn rm'd it.

Take them by name, or ask for them:

    vote-passed --release 9.7.0 --old_version 9.6.0
    vote-passed --release 9.7.0 --no-cleanup
    vote-passed                              # asks for both

Anything not named is prompted for, each prompt saying what will happen to that
version. Positional arguments are now an error pointing at the named form, so
existing muscle memory fails loudly rather than quietly meaning something else.
Equal versions are refused and the release version must already be tagged.
RELEASE_VERSION and OLD_VERSION still work, with the flags winning over them.

Versions are validated by one anchored regex, shared with cleanup. A glob such as
[0-9]*.[0-9]*.[0-9]* accepts "9.7.0/", which is textually different from "9.7.0"
and so slips past the equality guard, yet SVN canonicalises the trailing slash -
cleanup would have deleted the release promote had just published. Anchoring also
rejects whitespace, v-prefixes, traversal and command characters before any of it
reaches an svn path.

The defaults behind the prompts were wrong too. The release version came from the
highest version tag, but releases are not monotonic: a 9.6.1 patch cut from the
9.6.0 line after 9.7.0 has shipped is newer in time but lower in version, so the
suggestion would have been the already-released 9.7.0. Order by tag creation date
instead - maven-release-plugin writes annotated tags, so that timestamp belongs to
the tag and survives fetches. The old version now comes from dist/release, the
only place that knows what this release actually replaces, with the version being
released filtered out so re-running after a partial failure cannot offer to delete
it.

Both detectors are genuinely best effort. Under `set -euo pipefail` a failed
svn ls, or a grep matching nothing - which is exactly the state after a partial
failure, when only the new release remains - aborted the release instead of
yielding no suggestion, leaving the "could not read dist/release" branch
unreachable. They now return success with empty output.

Testing the flags uncovered a bug that predates them and reached every command.
error() wrote to stdout, and resolve_version is always called as
`version=$(resolve_version ...)`, so its message was captured into the variable
instead of shown: releasing an untagged version aborted, correctly, but printed
nothing about why. info/warn/error now write to stderr. The email templates use
plain echo, so they stay on stdout and remain pipeable.