It needs to be if I want to be able to have several ports controlled by
one MCU.  It's set as part of the FUSB configuration, not in the INT_N
struct, since the latter isn't user-initialized and may disappear
entirely in the future.

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.

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.

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

I think so, anyway.  Testing with a heat gun didn't result in the Sink
resetting itself, so I'm not confident that I understand the FUSB302B's
over-temperature sensing mechanism.

I must point out though that I'm not confident that this
over-temperature protection is even useful.  The PD Buddy Sink doesn't
get hot on its own, and if it did, it might not even be from the device
it's powering, making a hard reset useless.  The spec says that we Shall
implement over temperature protection though, and that we Shall send a
Hard Reset message when it engages, so even though I take issue with the
requirement, I'll try to do what the standard says I Shall.

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.