It's all right with me if people use my implementation of USB Power
Delivery in anything.  This will make writing firmware for the PD Buddy
Dev a lot more reasonable, once it exists.

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.

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

PPS APDOs are second priority, behind fixed supply PDOs.

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.

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.

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.

/!\ BROKEN BUILD /!\

This commit moves the library code to the library directory.  This
causes the firmware to not compile.  A few changes were made to reduce
the nubmer of errors, but some errors just aren't going to go away until
I go ahead with the planned changes.

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.

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.

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.

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.

There are still a few things that the standard says we Shall do and we
don't, but it Works For Me™.  I haven't implemented anything with
regards to GiveBack support, but that doesn't matter just yet.  Our
handling of VDMs isn't quite right either.  Anyway, it successfully
negotiates with so-called Split PDO power supplies, which is more than I
can say about some commercial products.