Match npm's behavior with non-semver version specifiers

[Silic0nS0ldier]

Currently non-semver version specifiers simply act as an override. This is not how npm handles it.

When faced with this situation, npm would pull the package.json from the specified location (git, GitHub, or local path), and continue dependency resolution as normal. At this point, its treated as a plain ol' locked down version specifier.

Logically, this is looking like:

incoming; // The incoming version specifier
current; // The current version specifier, a reference like a git url

let currentVersion = magicPackageJsonGetMethod(current).version

// Valid version number
if (validVersion(currentVersion )) {
  // Incoming is semver or version
  if (isSemverOrVersion(incoming) {
    // Check for conflict
    if (!inRange(currentVersion, incoming) throw new Exception('Conflict')
  } else if (/*Another reference like a git url (╯°□°）╯︵ ┻━┻*/) {
    let incomingVersion = magicPackageJsonGetMethod(incoming).version
    if (validVersion(incomingVersion)) {
      // Check for conflict
      if (!inRange(currentVersion, incomingVersion) throw new Exception('Conflict')
    } else {
      // Version not defined or not a real version value. (╯°□°）╯︵ ┻━┻
    }
  }
} else {
  // Version not defined or not a real version value. (╯°□°）╯︵ ┻━┻
}

Hardest part in this should be handling the discovery of the package.json's. For later reference, these pointers should help.

1. Git urls always have the protocol included. Identifying these should simply involve a isURL check of some kind. Or maybe some protocol check, since this can include @. Taking a peak at the npm source might help on this one.
2. GitHub urls can look really similar to a folder path, which isn't actually much of a problem.
3. Local paths always have file: before the actual path.

IMPORTANT: Addressing this changes behavior in a backwards incompatible way. A major version bump will be required to release this.