Now if we make a request for a PPS APDO, the SinkPPSPeriodicTimer is
run, forcing a new request to be made every 10 s.  This is important
because without it, the Source Shall perform a Hard Reset 15 s after the
request is made.

This state requires that the DPM be informed of the receipt of a
Not_Supported message.  Some DPMs may not need to do this, so the new
dpm.not_supported_received function is optional.

Now when a part of a chunked extended message is received, the
ChunkingNotSupportedTimer is run.  When it times out, we transition to
PE_SNK_Send_Not_Supported.  Just like the spec says.

In PD 3.0, there's a new control message, Not_Supported, which is sent
unsurprisingly when unsupported messages are received.  Basically, every
time we had sent a Reject message in PD 2.0, we're now supposed to send
Not_Supported instead.  As of this commit, that's exactly what we do.

Based on the first message sent from the Source, we now set the
Specification Revision field of our messages to 2.0 or 3.0.  We don't do
anything else 3.0 yet though, so it's a bit of lie, but this is a
necessary first step.

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 we're using millivolts internally rather than centivolts.  This
might be a good choice if USB-IF decides to make even more finely
adjustable voltages in the future.  If they don't, well, it still allows
voltages up to 65.535 V, which is beyond what some electrical codes
consider "low voltage", so I doubt USB will ever exceed that.

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.

This commit changes back to the original plan of having one set_vrange
command that sets both the vmin and vmax at once, instead of separate
set_vmin and set_vmax commands.  This will allow checking that the range
is valid every time it's set instead of having to wait until
configuration is written to flash.

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.

Now instead of checking the Var/Bat flag, it checks if either end of the
range is non-zero.

This adds specifications for the new configuration interface features
planned in this article:
https://hackaday.io/project/20424-pd-buddy-sink/log/68316-new-configuration-for-firmware-120

They were already mostly in sections, but without headers.  This commit
moves all the commands under new categories in the console_config.md
documentation file.

The new tempate variable sets the data role, power role, and
specification revision in one fell swoop.  It's used by the PE and DPM
alike for creating messages, and in the future it may have a part in
determining if we're doing PD 2.0 or 3.0.

It only shows the library's structure, not the PD Buddy Sink part of the
firmware.

Now simple Sinks are easier to implement, as not all DPM functions have
to be provided.

All those comments in pdb_dpm.h aren't needed anymore.  They were just
to help me organize my thoughts on how the DPM should work.

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.

This commit splits the old messages.h file into two, one private
(messages.h) and one public (pdb_msg.h).  This new arrangement keeps the
old model of one message pool for all the PD Buddy firmware library, but
moves the macro for the number of objects it contains into a new file,
pdb_conf.h, placed at the project root.  The pool itself is kept in the
new pdb_msg.h file, since the DPM may need to access it.

The new configuration file also contains the stack sizes for the PD
Buddy threads (some will be moved back to secrecy in the future once the
needed sizes are known, but the PE's stack size should be kept in
pdb_conf.h since user code needs that stack).

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_.

Again, shining example and whatnot.

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.

Now all the FUSB302B functions exclusively use the struct
pdb_fusb_config to know how to communicate with the chip.

Now the user-visible FUSB302B functions all take a struct
pdb_fusb_config * as a parameter.  The static functions don't use it
yet, but at least the public API of this code is in its finished state.

It was a hidden static variable of the policy engine, which would've
been a problem in a multi-port device.  Now it won't be anymore.

Apparently one of the threads was using too much stack space??  This
will require investigtion later, but for now increasing their stack
space fixed some weird problems I was having with this patch.

It isn't used there, so it doesn't need to be included.