fix: do not use cwd when resolving package.json for yargs parsing config

[nexdrew]

Fixes a bug introduced with #556, demonstrated by https://github.com/laggingreflex/yargs-test-720.

Also, while investigating changes from 556, I found that validation logic for the .implies() method interprets a prefix of --no- on a key as a tiny DSL for "when this key is not given". From this, we can actually ignore the boolean-negation: false setting for the .implies() method because boolean-negation affects parsing but not the DSL of implications. To demonstrate this, I added some tests (with comments) showing how the DSL is interpreted.

The following use-cases are supported for .implies():

1. bar: 'foo' = use of --bar requires that --foo be given
2. bar: '--no-foo' = use of --bar requires that --foo cannot be given
3. bar: 'noFoo' = use of --bar requires that --noFoo (or --no-foo with "boolean-negation": false) be given
4. bar: '--no-noFoo' = use of --bar requires that --noFoo (or --no-foo with "boolean-negation": false) cannot be given

In all use-cases, the boolean-negation config setting only changes how --no-foo (or --no-ANYTHING) is parsed in argv, it does not change how the implications are interpreted.

Thus, I also reverted 556 in its entirety.

Note that this fixes the bug found by #720, but it technically doesn't close 720 because I have not attempted to change the API to allow parsing config to be defined in any other way besides a "yargs" stanza in package.json.

[bcoe]

make sure that you test both inside a project directory and when something is installed with -g, but looks good to me.

I think we should encourage folks to use the yargs configuration, and avoid introducing a way to explicitly update these settings -- unless someone makes a really compelling argument.

It starts to get confusing; am I configuring yargs? am I configuring the settings for the library using yargs?

[bcoe]

@nexdrew I tested with yargs-test-720 installed with -g and from the folder. worth noting that it would have always worked when run form the containing directory, which is how we missed this.

[bcoe]

@nexdrew this is going out in the next release of yargs, would love your help testing:

npm cache clear; npm i yargs@next