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.

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

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

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.

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.

/!\ 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.

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.

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.