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.

Previously, we didn't make use of the voltage range when checking a
Type-C Current advertisement.  That was bad, since if e.g. we want 6 V,
with the range 5-7 V, we could get the power we want from Type-C
Current.

This commit makes the firmware test if the configured voltage range
contains 5 V, and if it does, allows use of Type-C Current.

Now the DPM tests if the configuration holds a current or a power, and
if it's a power, it calculates current at the necessary voltage(s) based
on that power.  This is used when making requests, when advertising our
Sink_Capabilities, and when checking Type-C Current advertisements.

Previously, the PDO attribute getter macros took a capabilities message
and the PDO index.  This worked in a lot of cases, but not in some I
need now, and there was little advantage to them working they way they
did anyway.  Now they take just the PDO itself, which is more intuitive
and more useful.

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.

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.