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.

It's pretty easy to implement, it turns out!  A new event gets sent to
the protocol TX thread when the PE is starting an AMS.  Just before the
message is transmitted, the TX thread checks if that event was received,
and if it was, it waits for the Type-C Current to look like 3.0 A
(SinkTxOk) before proceeding.  Now, to the best of my knowledge, we're
actually doing Power Delivery 3.0 as correctly as we ever did Power
Delivery 2.0, which is to say, everything is right except we don't do
BIST.

With PD 3.0, the highest voltage is 21 V (available on 20V Prog APDOs).
The firmware now allows that voltage to be configured.

According to the USB Power Delivery Specification Revision 3.0, Version
1.1, section 7.2.3.1, we're not required to enter Sink Standby when
changing the negotiated voltage on a single PPS APDO.  Now we don't.
This is done in the PE, so the DPM doesn't have to lift a finger to
avoid the unnecessary standby.

PPS APDOs are second priority, behind fixed supply PDOs.

Ooh, a new kind of entity in the diagram!

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.

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

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.

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.

These new headers define structs for configuring the library.  They're
currently unused, and some function prototypes no longer match.

For now, the new <pdb.h> file only has a function to start the library,
based on the old start_pd function from main.c.  It'll eventually be all
a user needs to include, but there's a lot more refactoring to do.