Leverage rollup's --config* feature for choosing bundles

[jasonkarns]

Summary

Rollup provides a feature specifically designed for passing in config
options to the rollup configuration module. That is: --config-* options.
(It is documented deeply under
https://rollupjs.org/guide/en/#configuration-files )

I believe this is a superior mechanism for passing options to rollup's
config because they do not impact process.env.

Environment variables have a very specific capability, which is that
they are inherited by child processes. These are settings that quite
literally "configure the environment under which a process runs".
They are the correct tool for setting env vars that should be set
within node during compilation, but not a proper replacement for
cli "flags".

Their use prior to this commit was an abuse in order to simply
pass an option to the rollup configuration that would control which
bundles to build. Rollup's --config* feature is superior for this role,
because the option is only intended to go so far as the configuration
module itself. Thus, using them to control which bundle(s) are built
does not leak extraneous information into the ahem environment of the
build process.

As a side benefit, the cli invocation is cleaner!

Another major benefit of this is that it allows explicitly choosing a
subset of bundles to build. ie:

• rollup -c --config-cjs to build all commonjs bundles
• rollup -c --config-json --config-umd to build the jsonSchema bundle
  and the UMD bundle.

And since the flags match on substrings, cross-matrices are supported, too.

For instance, say the following bundles were available:

• cjs-node, cjs-react, cjs-browser, esm-node, esm-browser

It would be possible to build all the node bundles or all the ESM bundles,
or all the cjs bundles or esm bundles.

rollup -c --config-esm
rollup -c --config-cjs
rollup -c --config-node
rollup -c --config-browser

Notably, the implementation dedupes the options, so if a given bundle
is matched by multiple flags, it's only built once.

This implementation is flexible so users may build precisely the bundles
they want, without waiting on extraneous bundles to build.
The developer ergonomics are clean so it's simple when invoking the rollup
CLI directly.
And the flags themselves are clean explicit enough that intent is "clear"
when being read from npm-scripts. (ie, "self-documenting")

A couple other quick nits in this PR:

• the pre-build step is extracted to an npm-clean script, per convention.
• the clean script is invoked automatically before building. (leveraging
  npm's pre/post hooks keeps scripts clearly explicit as to their primary
  purpose)
• the rollup config variable names are changed to reflect what they
  represent. ("config" is an overly general term. each rollup config represents
  an output bundle, so that term is used instead. I mean, the entire
  rollup configuration module is "config" so... that's almost meaningless)
• the common cjs helper function is renamed (virtually every function
  "gets" something. prefixing a function with "get" is akin to doFoo.
  this dispenses with the imperative naming and names the function
  for what it returns. Because a function's name at the callsite is literally
  replaced with its return value, so what it returns is what it should be
  named.)
• runs prettier on the entire config to clear up any inconsistency
• adds an unminified ESM output bundle:
  many ESM consumers will be running their own rollup/webpack
  bundlers, and therefore doing their own minification. Providing
  an unminified ESM entrypoint makes their debugging easier.

(Last note, a portion of this PR is whitespace thanks to prettier,
so when reviewing the diff on github, disabling whitespace will make
the rendered diff smaller/cleaner.)

[mjc1283]

LGTM. Agree that the --config option is a better approach than environment variables. Also the unminified ESM output is great to have.