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.

When there is a positive or negative transition of Vbus, we Shall reduce
our power consumption to no more than 2.5 W beforehand.  This can be
easily achieved in all cases by simply turning off the output. This was
implemented, so that's one fewer Shall we aren't doing.

In the process, I made some API changes for the Device Policy Manager.
No more output_on() and output_off(), now it's output_set(true) and
output_set(false), plus a special case output_default() used during a
hard reset.  This much better matches how these functions are used by
the policy engine.

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.

After a failed hard reset, we keep trying to negotiate power.  Before,
the LED was on steady indicating negotiation failure during these
continued negotiations.  Now it keeps blinking, indicating what's
actually going 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.

In the PE_SNK_Select_Capability state, we Shall do some transitions if
we receive a Wait or Reject message.  Now we do.  This creates another
TODO (running SinkRequestTimer in the PE_SNK_Ready state), but this
one's only for a Should, not a Shall.

Ultimately the handling will be more interesting than this.  For now
though, we don't support them, and so we Shall reject them.

From the USB PD spec, Revision 2.0, S. 6.4.4.1:

* A DFP or UFP which does not support Unstructured VDMs Shall Ignore
  any Unstructured VDMs received.

From S. 6.4.4.2:

* A DFP or UFP which does not support Structured VDMs Shall Ignore any
  Structured VDMs received.

Therefore, as long as we do not support any VDMs, we Shall Ignore them,
which is exactly what we're doing.  We're not doing anything wrong, so I
removed the TODO comment that implied we were doing something wrong.

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.