Gavin had trouble with configuration because it isn't loaded on startup.
I realized that I've been caught with the same mistake myself before, so
since at least 2 out of ~65 people have done this, it's clearly a real
usability problem.

Now the configuration is automatically loaded from flash when setup mode
starts, so there's no need to type `load` to edit the configuration the
Sink already has.  If you're changing all the settings, you'll have to
type them all anyway, so I don't think there will be any surprises
because of this change.

A new bit was added to the Source Fixed Supply PDO in PD 3.0, saying
whether the source supports unchunked extended messages.  It's not
really relevant to the PD Buddy Sink since it itself doesn't support
them, but users might want to know and it's very little work to print
it, so now it does.

Technically I updated to a development version somewhere between 17.6.3
and 17.6.4, but I don't doubt its stability.

This is a good update because I'd like users of the library to be
confident that it works with the latest version of ChibiOS.
Interestingly, none of the changes I made were in the library code, so
it did before, but now I know for sure.

I'm unclear as to whether I can now get rid of the INT_N thread in favor
of a pin interrupt.  I'll have to see if I can, or if that will have to
wait for still more ChibiOS updates.

The PD Buddy Sink code should define PDBS macros, not PDB macros.

After much poking around, I finally figured out how to make this work!
The problem was that the ChibiOS initialization code had disabled
interrupts before the __early_init function was run, making the
bootloader not work despite my best intentions.  This was fixed by
enabling interrupts just before jumping to the bootloader.  This in turn
required changing to GNU-flavored C11 to include an inline assembly
instruction.

This commit adds support for configuring the current requested from the
power supply in the form of a resistance.  This is useful for powering
resistive loads when a voltage range is configured.

This commit adds the `set_p` command for setting power, and the `p`
configuration field for reading it back.  There is no support for making
requests based on power yet (the field is still interpreted as a current
unconditionally).

Now the Sink_Capabilities message contains a PDO from inside the range
if applicable, and a PPS APDO if we're using PD 3.0.

Just as described in console_config.md.  Soon the DPM will even use the
range when making requests.

This commit breaks old configuration by interpreting stored voltages as
millivolts, rather than 50 mV.  This will allow the finer voltage
increments used by programmable power supplies to be specified.

Now the commands are in the same order in shell.c, the printed list, and
console_config.md.

Now the CURRENT_DEFN field of the flags halfword in the pdbs_config
object is actually used, both when printing configuration objects and
when setting a current.  It never takes any value other than 0 (_I) yet,
but this easily extends to power and resistance.

This commit adds the toggle_hv_preferred command, and makes printed
configuration objects show the state of the HV_Preferred flag.  The
flag still isn't used by anything else yet though.

Due to a typo, it would clear all bits except the HV_Preferred bit.
This commit fixes the bug, and refactors the clearing code to make typos
like this harder to make.

Firmware 1.2.0 will have more configuration flags than previous
versions.  This commit adds macros for those flags.  There's also a
field added to the flags halfword that says whether a current, power, or
resistance is configured, so this commit makes the clear_flags command
not modify that field.

All the internal functions and definitions have been moved out of
lib/include/.  Includes are made with the semantically correct brackets
("" or <>) throughout the firmware and library.  That is to say, the
library is essentially done at this point, with only documentation
changes left to be made.

To do this, a couple of the events had to have their definitions moved
to lib/include/pdb_pe.h.  This isn't a problem in and of itself, but if
more internal-use events are added to policy_engine.h there could be
trouble.  To mitigate this, I added a comment as a reminder to make sure
any new events don't overlap the public ones defined elsewhere.

Their names were a bit too greedy for the global namespace, so I
changed them to start with fusb_tcc_.

Not the static globals yet, just the public ones.  I suppose this change
isn't technically necessary since the PD Buddy Sink is a single-port
device, but I want its firmware to be a shining example of how to use
the library.

It's not general-purpose PD Buddy code, but rather PD Buddy Sink code.
Therefore it gets the pdbs namespace.

The code compiles again, and it seems to work as it did before.  There's
still a lot to do (we still have a mess of globals), but the PE
correctly calls the new DPM functions via the list of callbacks in the
configuration object.

The "storage" source code files contained lots of stuff with "config" in
the name, but nothing named "storage".  This was unlike every other part
of the firmware, so I renamed the files to "config".

The received Type-C Current advertisement is now kept in a global
variable which can be read by the command shell.  When there are no PD
capabilities but there is Type-C Current, the typec_virtual PDO is
reported as the one and only PDO.

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.

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.

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.

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.

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?

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.

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

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.