refactor: args to flags

[bcoe]

Based on #12, and sifting through online conversations like this, this refactor
proposes using the terminology "args" for options that take arguments,
and "flags" for options that are boolean.

Fixes #12

[bcoe]

CC: @shadowspawn

[shadowspawn]

Short version: I think it is an improvement. 👍

[ljharb]

I would say that "args" is an umbrella term that includes flags. it's "yargs", not "yvalues" or "yparams" :-p

[shadowspawn]

To expand a little:

• I think flags is much better than using args for the boolean options
• this PR uses "args" for the "option arguments" which is a justification but a little subtle. Could be optionArgs, but then should it be optionFlags for symmetry? Names are hard! (And I care.)
• I was ok with values

I would say that "args" is an umbrella term that includes flags.

Seconding that viewpoint, the routine we are implementing is called parseArgs. 🙂

[shadowspawn]

Of note for consistency, the configuration property for setting up the parsing is called withValue.

[bcoe]

so we're leaning towards flags and values? and dropping uses of args?

[bcoe]

@iansu @shadowspawn @ljharb take a look.

[shadowspawn]

LGTM

(Changed title to match latest code.)

[shadowspawn]

👍