Section 9: Clarify pre-release definition

This is cherry picked from #103 and related to #86

- Remove confusing 'satisfies' usage.
- Specify that pre-release identifiers cannot be empty.

I'm actually not happy about removing the 'satisfies' usage.

If I understand @isaacs concern correctly, stating that `1.0.0-beta` satisfies `1.0.0` implies a specific version range implementation and he is against that because other systems have different ways of specifying version ranges.

For NuGet, we've taken to using the Maven range specification. `[1.0, 2.0)` indicates a version that's `1.0 or greater, but strictly less than 2.0`

According to SemVer as it is today, `1.0.0-beta` fits within that range. That's the intent of 'satisfies' even though it is less than `1.0.0`. The way I often think about it is when you allow pre-release versions in your dependency resolution, `1.0.0` can be considered `1.0.0- Ω` where `Ω` has a larger precedence than any valid pre-release version.

I think we can get to a definition that expresses our intent without implying a specific implementation.

Something to the effect of:

```
When pre-release versions are allowed to be included in version comparisons (such as in dependency resolution
algorithms), a pre-release version SHOULD be included in any set that it's associated normal version is, but have
lower precedence than its associated normal version.
``` 

^^^ The language there could be improved, but I think it hints at what I'm getting at. Pre-release is adding another dimension. Kind of like adding something to the y-axis while we've been looking at the x-axis all along.

How pre-release versions are "allowed" to be included is an implementation detail of the respective systems. For some, it might be indicated by the version range syntax. For others it's by passing a `-pre` flag into the system.

What do you think?

/cc @isaacs, @tieske, @TimLovellSmith, @tbull, @jeffhandley