Improve tokenization of version strings

Tokens like "b4", "beta1", "p195", &c. are now treated as atoms rather
than being broken down even further. Additionally, we enable support for
padding in the middle of versions strings, so we can successfully
compare something like "2.1-p195" with "2.1.0-p194" by inferring that
"2.1" is really "2.1.0".

This fixes the comparison "9.9.3-P1" > "9.9.3" which previously has not
been handled correctly.
Enable tracking of formula revisions

It is useful to be able to prompt upgrades in response to events other
than a version update; for example, when a dependency is updated and its
library version changes, dependents need to be rebuilt to link against
the new library.

Currently we cannot do this automatically, which means a flood of
tickets whenever the library version of a popular library changes.

To address this, we need to track an additional piece of metadata, the
"revision" of the formula, which can be incremented when appropriate to
prompt an upgrade. It can then be reset to zero when the next version
change occurs.
Encode formula revision in installation prefix

In order to allow kegs built with the same version but differing formula
revisions to coexist, we must encode the revision as part of the keg's
name. This is necessary to actually perform an upgrade, as we cannot
upgrade a keg in-place, and temporarily moving it pending the result of
the upgrade is error-prone and potentially slow.

To accomplish this, we introduce a new Formula#pkg_version method that
concatenates the active_spec version, the formula revision, and the
bottle revision (if applicable). An exception is made for a formula that
has no revision: the tag is omitted. This preserves compatibility with
existing installations.
Teach outdated and upgrade to consider formula revisions
Incorporate bottle revision when building bottles