When there is a positive or negative transition of Vbus, we Shall reduce
our power consumption to no more than 2.5 W beforehand.  This can be
easily achieved in all cases by simply turning off the output. This was
implemented, so that's one fewer Shall we aren't doing.

In the process, I made some API changes for the Device Policy Manager.
No more output_on() and output_off(), now it's output_set(true) and
output_set(false), plus a special case output_default() used during a
hard reset.  This much better matches how these functions are used by
the policy engine.

Before, we were doing the O(1) configuration loading operation every
15 ms, which just made me feel dirty.  Now we do it only the first time
we check the available Type-C Current, and then cache its location.
This works because it never moves without rebooting into setup mode.

Type-C Current is a mechanism defined in the USB Type-C spec for
indicating high-current modes at 5 V using nothing other than a voltage
on the CC line.  The FUSB302B maps the voltage to one of the four ranges
we care about, so it's easy to see if 1.5 A or 3 A is available at 5 V
even in systems that don't support PD.

Now, when the PD Buddy Sink is connected to a system without Power
Delivery support, after all attempts at PD communications fail, it falls
back to Type-C Current.  If the Sink is configured for 5 V, it will
monitor the CC line's voltage to see if enough Type-C Current is
available.  If so, the output is turned on.

After a failed hard reset, we keep trying to negotiate power.  Before,
the LED was on steady indicating negotiation failure during these
continued negotiations.  Now it keeps blinking, indicating what's
actually going on.

It was a uint8_t before, but it was really just a boolean variable.
It's a proper bool now, and the code that sets its value is less
ridiculous.

Before, it was repetitive and hard to expand.  It would have become a
big ugly decision tree upon adding support for variable and battery
PDOs.

Now it's been refactored to be a procedure, appending PDOs to the end of
the list and building the message header at the end.  The code isn't
repetitive, and new features can be added more easily.

The command shell is based on the ChibiOS-provided one, but modified to
not run in a new thread and generally be a bit simpler, while also
having PD Buddy branding.  The storage functions work with the STM32
flash registers directly, taking over the last page of flash.  A new
linker script is used to ensure that program code can't end up using
that page.  The DPM has been updated to use the saved settings rather
than hardcoded ones.  Now what's needed is real commands for editing the
configuration.

Added commands to edit configuration

We now have commands to load the current settings into RAM, edit the
settings in RAM, and write them back to flash.  The only settings
currently supported are current and fixed voltage, because the rest of
the code doesn't support GiveBack or variable/battery PDOs yet.

Short help messages were added for each command.  Nothing too exciting,
but it should be a great help for someone poking around in the PD Buddy
Sink configuration shell for the first time.

Wrote new usage information for the firmware

Now that we have a command shell, the README should indicate how to use
it.

There are still a few things that the standard says we Shall do and we
don't, but it Works For Me™.  I haven't implemented anything with
regards to GiveBack support, but that doesn't matter just yet.  Our
handling of VDMs isn't quite right either.  Anyway, it successfully
negotiates with so-called Split PDO power supplies, which is more than I
can say about some commercial products.