Seems some of the instances did not get replaced in #c4aa65618ec8b5eeb77ab2893a918746f0deeaf8

Credit: @OiYouYeahYou

…ry consumption

PR-URL: #38
Credit: @iarna
Close: #38
Reviewed-by: @isaacs

Gists are either name/hex{32}, or just /hex{32}.

If someone omits the project, and just specifies a name, then that is an
error and should be treated as such.

Also, eliminate some dead code paths and bring the tests up to 100%.

…ps URL

PR-URL: #47
Credit: @mterrel
Close: #47
Reviewed-by: @isaacs

PR-URL: #44
Credit: @ybiquitous
Close: #44
Reviewed-by: @isaacs

Related:
- #25
- #40

This removes the require('util') fallback for Object.assign, without
dropping support for node v4 (which will happen on the next major,
likely along with 6), but gets bundle sizes down in the meantime.

It's much less friendly to use this library (and those that depend on
it, like npm-package-arg) when it's not clear whether the returned value
is a member of a class (which likely has some useful methods) or just an
object full of data that the user is expected to know what to do with.

This is especially vexing since some of this sort of data is saved to
various lock and config files, so _sometimes_ a thing that looks
suspiciously like a GitHost object actually is just a plain old JS
object.

Technically these are called groups and subgroups in GitLab parlance,
but effectively, it means that a GitLab project url can have a path with
unlimited portions, like company/property/team/component.git.

This allows passing in unlimited path portions in the full url, and
avoids encoding the `project` section akin to how `path` is treated as
of 3776fa5 #44

Fix #46
Fix #43