Track incoming UpdateAddHTLC until HTLC resolution

Currently, we decode HTLC onions immediately upon receiving an
`update_add_htlc`. Doing so determines what we should do with the HTLC:
forward it, or immediately fail it back if it cannot be accepted. This
action is tracked until the HTLC is fully committed to by both sides,
and a new commitment in the latter case is proposed to fully remove the
HTLC. While this has worked so far, it has some minor privacy
implications, as forwarding/failing back do not go through the usual
`PendingHTLCsForwardable` flow. It also presents issues with the
quiescence handshake, as failures through this path do not go through
the holding cell abstraction, leading to a potential violation of the
handshake by sending an `update_fail_*` after already having sent
`stfu`.

This commit serves as a stepping stone to moving towards resolving HTLCs
once the HTLC has been fully committed to by both sides. The first step
in resolving an HTLC is decoding the onion encoded to us, which is
included in the `UpdateAddHTLC` message. Unfortunately, switching over
is not a forwards compatible change, so we'll need to do so over
multiple releases. The first release should include full support without
actually enabling it.

Author: wpaulino