Since the spec says we Shall request no more power than we actually
need, we were violating the spec whenever the output was disabled in
Setup mode.  This commit fixes that, requesting low current at 5 V when
the output is disabled.

We do play a little fast and loose with the MAX_CURRENT field, but
that's hard to avoid in a device like this.  Well, we could always set
it to 5 A in Setup mode to be safe, but that's not necessarily right
either.  At least it's still honest in Sink mode, which I consider more
important anyway.

We don't need to update the source's capabilities when setting our
output state.  Now we just send a new Request.  For now, that request is
redundant, but soon I want to make the Sink request less current when
the output is disabled.  Whether the voltage should be the same or
always vSafe5V in that case, I haven't decided yet.  There are
advantages to each, but the difference is so minor in terms of using the
device that I don't see a reason to let the user choose, which of course
puts the decision on me.

It was never really necessary to update the source capabilities before
making sending a Request message.  It was convenient though, since we
didn't store the previous Source_Capabilities message.  Now we do, so
it's possible to make a new Request based on that.

This commit makes the Sink do just that.  It doesn't follow the spec's
state diagram for this, but it's a minor change that works better with
this firmware's design, so I don't mind.  There's a comment explaining
that too, so future folks won't be confused by it either.

The `PDO n:` and `type: blah` lines have now been combined into a single
`PDO n: blah` line.  This saves one line per PDO, and still makes plenty
sense.

When we were getting power from Type-C Current advertisements, we used
to not update the location of the configuration object.  This was done
to save time between polling the Type-C Current, and was not a problem
until we started trying to do Power Delivery in Setup mode.  As the
comment correctly said before, when we were trying to get power, the
location of the configuration object wouldn't change, so there was no
need to find its location more than once.

Now that the location of the configuration can change while we're
getting power, we need to check if that's happened.  This can be easily
done by checking the configuration object's status.  If the status is
not VALID, we get the location of the new configuration object.

It prints the most recently advertised PDOs in a reasonable format.  The
types it doesn't know about are printed as hex so that someone
knowledgeable can still get the information they need.  For now, it only
knows about fixed PDOs, so variable and battery PDOs will be shown as
hex.

Since this means we remember the most recent Source_Capabilities, it's
now becoming possible to send a new Request without sending a
Get_Source_Cap message first.  That's not actually done yet, but I'd
like to do it that way.  I'd also at some point like to make a
lower-current Request when the PD Buddy Sink's output is disabled, but
again, that's still to come.

Just as specified last night.  This represents the completion of a big
part of the new interactive Power Delivery features of the shell.
Next up: printing the source's advertised PDOs.

When running in Setup mode, the Sink is capable of USB communications.
Now it's honest about that in the Request and Sink_Capabilities
messages.

The PD Buddy Sink now requests new power after configuration is written.
This means that in Setup mode, the voltage and current can be
re-negotiated on the fly.  Cool, huh?

It's still impossible to turn the output on and off from the shell.  New
commands will allow that soon enough, though.  Also, I'm seeing some
weird behavior when switching to/from 5 V (power shuts off entirely
sometimes), but I suspect that's a quirk of the source I'm using (Asus
USB 3.1 UPD Panel) and not the PD Buddy Sink itself.  I plan to make or
buy a USB power/data splitter to verify this.

The DPM used to always set the LED to indicate the PD status.  This
caused fighting when the PD threads were run simultaneously with the
shell, making the LED show different things depending on what commands
the user ran.  Not cool!

This commit adds a bool pdb_dpm_led_pd_status, which prevents the DPM
from setting the LED when set to false.  This commit also sets it to
false before starting the PD threads in Setup mode, allowing the shell
to be in full control of the LED.  Right on!

A good first step towards the upcoming 1.1 release, this commit runs the
Power Delivery threads in Setup mode.  This required a slight change to
the shell to make it non-blocking, as otherwise the PD threads would
never get to run.

There's still a lot to do!  The shell and the PD threads fight over
control of the LED in Setup mode.  There's no way to make the PD threads
re-negotiate the required power.  There's also no way to turn the output
on or off from the shell.  None of these changes should be too major,
but together they'll be pretty cool when they're all done.

The shell main loop function and text input function were dreadfully
devoid of comments.  This simply could not continue, so I added a
sprinkling of comments to each, as well as to important sections of the
file.  Further, I changed the special character values to look like
characters rather than numbers, which should aid in understanding.

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 VID:PID pair 1209:9DB5 is now officially assigned for the PD Buddy
Sink.  Thanks, Arachnid!  Now the firmware uses its proper PID instead
of the testing one.

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.

There's not really any harm in writing a configuration with zero voltage
or current (and it was possible all along anyway), so why fight it?

It's more obvious what is meant by that macro than by just the number
100.

The manufacturer should be PD Buddy, and the product should be Sink.
And so it is.

Now we correctly set the GiveBack flag and minimum current fields in the
Request message when GiveBack is enabled.  Also when GiveBack is
enabled, we correctly handle GotoMin messages by lowering our power
consumption, completing negotiation, and Requesting our normal power
periodically until the power supply Accepts our Request.

At least, I believe it's correct.  I don't have any hardware that sends
GotoMin messages, so I can't test it other than that it doesn't break
anything with the GiveBack flag set to 1 or 0 when the source doesn't
ask to reduce power.

As the name says, it toggles the GiveBack flag in the configuration
buffer.  The rest of the firmware doesn't use the flag for anything yet,
but it is correctly saved in flash.

We used to free the Request we made after transmitting it.  However, for
GiveBack to work properly, we need to be able to make that request
again.  To do it without having to request the Source_Capabilities
again, it makes sense to keep the Request message in memory.  We have
more messages in the pool than we need anyway.

The policy engine is supposed to transition to the
PE_SNK_Transition_to_default state from any state when hard reset
signaling is received.  While it still doesn't do that exactly, in every
state that already waited for events, the PDB_EVT_PE_RESET event is also
checked, with the appropriate transition being made if the event is
received.

My justification for not checking for the event in other states is that
if there's no wait, the reset will be received soon by another state
anyway.  Besides, if there's no event handling already, where exactly
would be best to insert a test for the event?

I think so, anyway.  Testing with a heat gun didn't result in the Sink
resetting itself, so I'm not confident that I understand the FUSB302B's
over-temperature sensing mechanism.

I must point out though that I'm not confident that this
over-temperature protection is even useful.  The PD Buddy Sink doesn't
get hot on its own, and if it did, it might not even be from the device
it's powering, making a hard reset useless.  The spec says that we Shall
implement over temperature protection though, and that we Shall send a
Hard Reset message when it engages, so even though I take issue with the
requirement, I'll try to do what the standard says I Shall.

The README now outlines the features of the PD Buddy Firmware.

A bit of documentation was added to main.c, along with renaming the
pd_buddy() function to sink().

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.

It's simpler than I realized.  All that's left to do here is the
fallback mechanism for when the Sink is configured for 5 V.  This means
that yet again, a TODO was replaced with another, less critical TODO.

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.

In the PE_SNK_Select_Capability state, we Shall do some transitions if
we receive a Wait or Reject message.  Now we do.  This creates another
TODO (running SinkRequestTimer in the PE_SNK_Ready state), but this
one's only for a Should, not a Shall.

Now we use more consistent language to refer to the stored configuration
(which is in flash) and the configuration buffer (RAM).

Ultimately the handling will be more interesting than this.  For now
though, we don't support them, and so we Shall reject them.

From the USB PD spec, Revision 2.0, S. 6.4.4.1:

* A DFP or UFP which does not support Unstructured VDMs Shall Ignore
  any Unstructured VDMs received.

From S. 6.4.4.2:

* A DFP or UFP which does not support Structured VDMs Shall Ignore any
  Structured VDMs received.

Therefore, as long as we do not support any VDMs, we Shall Ignore them,
which is exactly what we're doing.  We're not doing anything wrong, so I
removed the TODO comment that implied we were doing something wrong.

PD uses odd units for voltages and currents.  Power too, but we don't
work with power (yet).  In the shell, we have to convert to and from
these odd units.  We had been doing this in-place every time, which was
a bit crumby.  Now it's done with macros in pd.h, making prettier and
more maintainable code.

The configuration interface is done, so we shouldn't have any comments
that say otherwise.  Also, since the shell never exits, it's silly to
put the code that runs it in a loop.

The command-line interface now shows license information if you type the
"license" command.  Now users can be easily made aware of their
freedoms.

The GUI will have a button to identify a particular PD Buddy Sink, in
case several are connected to the computer at once.  The button will
cause the LED to blink quickly for a couple seconds, then go back to
normal.  To allow this, I added a new LED blink mode (FAST_BLINK_SLOW)
that causes 8 fast blinks, then returns to SLOW_BLINK mode.  A new
"identify" command triggers this LED mode.

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.