Do not claim/reject all inbound HTLCs at once based on preimage/hash

[TheBlueMatt]

As of #167 we track HTLCs separately as required by BOLT 2 for privacy. However, we currently reject/accept all to-us HTLCs at once when the user gives us a preimage/no-such-preimage callback. This allows an attacker to (in a really race-y way) query us if we are the intended recipient of a payment that was routed through them by simply sending us a small value HTLC with the same hash as the one they saw. This will likely require an API change, and users may end up needing to do something like tracking the expected value of a payment and only fulfilling HTLCs that match the expected value (to the single-msat level).

[TheBlueMatt]

Of course tracking value would only work if we also add randomness to the fees we pay ala #158.

[TheBlueMatt]

I'm gonna unmark this 0.1 cause its not clear that its realistic to build something sensible without moving to something other than simple hash-based HTLCs.

[TheBlueMatt]

We've moved on to something "other than simple hash-based HTLCs" with requiring MPP/payment_secret.