Fix for issue #200: "Nightly builds not supported"

Implemented a suggestion that arose from discussion about lack of
support for development builds in which the version number for the next
official release is unknown. The suggestion is to replace the statement
that metadata MUST NOT be considered in precedence with a statement that
metadata SHOULD be considered in precedence, and that it has a higher
precedence than the corresponding normal or pre-release version.
Pull request also include additional details, examples, and one
additional FAQ regarding development builds.

The main justification for this change is that an increasingly common
develpoment model is fast paced and flexible, often with a fixed length
release cycle, or an as-needed release plan. In such scenarios, it is
commonly the case that one does not know what changes will be included
in the next release, and therefore does not know what semver should be
used for the next release until the release is ready (since changes to
the public interface are not known). The pre-release version identifiers
are therefore ineffective for between-releases versioning (i.e.,
development/nightly releases) because they have lower priority.
Therefore, a similar "post-release" identifier is required to support
this type of development.

The build metadata field was identified as an appropriate field to use
for this information, if it were to be considered with regards to
precedence. The following reasons for using the metadata field were
identified:

        1. Build metadata without impact on the precedence is
        unhelpful at best, and harmful at worst. If you two releases are
        not different in any way, they should have the same version
        number (i.e., they should be the same release). If they are
        different in anyway, they should be different versions and one
        should take precedence over the other.

        2. The pre-release identifier sequence are has lower precedence
        and is preceded by a "minus", the metadata identifier sequence
        is preceded by a "plus" and is therefore a fitting location for
        "post-release" identifiers with higher precedence.

The semver spec version number was tentatively bumped from 2.0.0 to
2.1.0. This is of course only a suggestion, but it seems like it could
fit as a minor change (i.e., an addition to the public interface). For
instance, existing semver implementations can continue to function
according to the 2.0.0 version without breaking, they just may not
support (for instance) upgrading to a post-release development version
because it will identify it as having the same precedence. An
implementation which wants to suppor the 2.1.0 addition could default to
the 2.0.0 behavior, and require an additional configuration / option to
allow such an upgrade to a development version. This is also fitting
because most users will not want to upgrade to development versions,
they will prefer to stick to official releases.

For more details, please see issue #200 on the original mojombo/semver
repository, in which a length discussion occurred.