The API for the new features is stable, and the implementation seems
complete and bug-free.  I can't see any reason not to release, so here
we go!

Each field's name and meaning is listed now, and the unsupported types
are no longer listed as if they are supported.  As always, I'd like to
support variable and battery PDOs, but I need hardware that sends them
to add such support.

Still preliminary, but the general idea is that each PDO will be printed
similarly to how a configuration object is printed, but numbered and
indented to make a nice human- and machine-readable list.

The new behavior of `write` has been documented, as well as a high-level
description of the new Setup mode behavior with Power Delivery
communications.

The new `output` command now has documented specifications.  Not a
single line of code has been written for it though, but this is isn't a
release so you shouldn't take everything the documentation file says as
true.

Now the error behavior for set_v and set_i is well-defined by the
documentation: they print nothing on success and an error message on
failure.  The range of valid values is now [0, 20000] for set_v and
[0, 5000] for set_i, matching the voltages and currents that can be
provided by USB Power Delivery.

Bumped version number to 1.0.1, reflecting this bugfix.

The iSerial descriptor now holds the firmware version number.  This is
1.0.0 since I don't expect any major API changes any time soon.  The USB
descriptors have been documented in docs/console_config.md so there
will be no questions as to how to identify the devices and what their
"serial numbers" mean.

The most useful thing from the stack of scratch paper I made while
designing the firmware.  Now it's immortalized as an SVG.

As the name suggests, it clears all the flags in the configuration
buffer.  This provides a way to easily set all the flags to a known
state, which is nice for implementing libraries that configure PD Buddy
Sink devices.

It's very important to document the format in which configuration is
printed, since being able to reliably read the configuration is
essential to implementing configuration GUIs.  Now it's documented, and
the format is considered stable.

Now there's a docs/ directory for storing our documentation in!