Iterative change moving us towards a more unified config.
No longer pulling config from flatOptions where we don't have to.

PR-URL: #2892
Credit: @wraithgar
Close: #2892
Reviewed-by: @ruyadorno

When not handled, when there are multiple entries in
this.npm.config.list, it causes crash as described in #2834

The change here merge everything in this.npm.config.list, because as I
observed, the default config is present only at the last entry.

Fix: #2834
Co-authored-by: @wraithgar

PR-URL: #2865
Credit: @kenrick95
Close: #2865
Reviewed-by: @isaacs, @wraithgar

This replaces the multiple separate sets of objects and documentation,
some of which had defaults and/or types, some of which didn't, and cleans
up a lot of configs that are no longer used.

Deprecated configs are now marked, and the approach used to create these
config definitions ensures that it is impossible to create a new config
option that lacks the appropriate data for it.

Eventually @npmcli/config will move back to the CLI under
lib/utils/config/, so this v2 will be a short-lived release family.

PR-URL: #2878
Credit: @isaacs
Close: #2878
Reviewed-by: @isaacs

Lots of dead code removed thanks to streamlining of logic.
`npm help` `npm <command>` and `npm help-search` are all now separated
concerns, handling their own use cases. `help` calls `help-search` as a
last resort, but `npm <command>` no longer tries to wind its way through
to `help-search` just to get the basic npm usage displayed.

The `did you mean` output has been expanded. It now always suggests top
level commands, scripts, and bins, and suggests them in the way they
should be called.

PR-URL: #2859
Credit: @wraithgar
Close: #2859
Reviewed-by: @ruyadorno

PR-URL: #2860
Credit: @varmakarthik12
Close: #2860
Reviewed-by: @wraithgar

PR-URL: #2869
Credit: @jansepke
Close: #2869
Reviewed-by: @wraithgar

PR-URL: #2872
Credit: @augustobmoura
Close: #2872
Reviewed-by: @darcyclarke

This was erroneously removed during a merge conflict

PR-URL: #2876
Credit: @chowkapow
Close: #2876
Reviewed-by: @wraithgar

PR-URL: #2881
Credit: @klausbayrhammer
Close: #2881
Reviewed-by: @wraithgar

- Add workspaces-related configs:
  - workspace: list of workspaces names/dir to filter for
  - workspaces: boolean value to enable/disable workspaces awareness
  - adds the proposed note in the docs of each of the commands
    that are not affected by these configs.
- Add workspaces support to `npm run-script`
  - add ability to serially run lifecycle scripts in workspaces
  - add ability to list scripts for all workspaces
  - add colors to `npm run` (no args) output

Relates to: npm/rfcs#117
Fixes: npm/statusboard#276
Fixes: npm/statusboard#283
Fixes: npm/statusboard#284
Fixes: npm/statusboard#285
Fixes: npm/statusboard#286

PR-URL: #2864
Credit: @ruyadorno
Close: #2864
Reviewed-by: @wraithgar

This is used by npm-registry-fetch to set the 'npm-command' HTTP header.

Will be cleaned up in a less ugly way in config refactor part 2.

PR-URL: #2903
Credit: @isaacs
Close: #2903
Reviewed-by: @wraithgar

Base commands and `npm run` need different outputs

PR-URL: #2906
Credit: @wraithgar
Close: #2906
Reviewed-by: @ruyadorno

This starts us down the path of tying the params our commands accept to
their config items.  For now it is optional, and not every current
config item would cleanly render if we added them today.

The ones that are added here DO render nicely, and we can iterate from
here.  We can also at a later date do the same kind of appraoch with our
positional args.

PR-URL: #2908
Credit: @wraithgar
Close: #2908
Reviewed-by: @nlf, @isaacs

Add workspaces support to `npm exec`
  - Refactored logic to read and filter workspaces into
  `lib/workspaces/get-workspaces.js`
  - Added location context message when entering interactive
  shell using `npm exec` (with no args)
  - Add ability to execute a package in the context of each
  configured workspace

Fixes: npm/statusboard#288

PR-URL: #2886
Credit: @ruyadorno
Close: #2886
Reviewed-by: @wraithgar

PR-URL: #2917
Credit: @wraithgar
Close: #2917
Reviewed-by: @ruyadorno

`npm exec <pkg>` was failing for packages not available in the local or
global scope due to the default value of the `yes` config having been
changed to `false` during the latest config refactor. That caused
`npm exec` to throw with a `canceled` error message since the current
implementation expects the default value to be falsy but not `false`.

This change reinstates the previous default config value for `yes` and
changes the implementation to throw with a proper error object in order
to get a stack trace when running with `--loglevel=verbose`.

The default value for the `which` config option used in the `npm fund`
command is now `null` instead of the previously used `undefined`.

Replaces usage of flatOptions with npm.config.

This was causing the progress bar to be flashing in between lifecycle
script runs.