NUT-07: add new field pending

[callebtc]

This is necessary in order for a wallet to determine whether a token it used for making a Lightning payment is still in-flight or not.

In short, LN payments can have 3 states but our tokens only 2 (because there's only spendable or not). We need another boolean state (pending).

Using this, wallets can determine the state of an outgoing Lightning payment as follows:

• if a token is not spendable and not pending, the payment succeeded
• if a token is spendable and pending, the payment is in-flight
• if a token is spendable and not pending, the payment failed

[Semisol]

This finally got proposed :D

[gandlafbtc]

LGTM

[BilligsterUser]

👍

[thunderbiscuit]

ACK 16e0a39.

I pointed a few non-blocking nits if you're interested.

Other ramblings/thoughts

A general thought on the wording of those token states (which might belong more in an issue than on this PR so feel free to ignore). It makes sense to have booleans in this json object for communication between the mint and client, but it might be nice to outline better wording for those states than the negation of spendable and pending as not spendable and not pending. In my mind, those two booleans immediately combine to become an enum, and I'm likely to call the enum variants something like spendable/burned/inflight or live/burned/pending.

This is more of an implementation detail (the json fields should probably stay spendable/pending) but as outlined in this awesome and very liked PR from Murch, providing good wording is always a big win. I guess what I'm proposing here is another PR that clarifies what the spec will call these token states. Something like this or a variant of it with your preferred words:

We call the combination of these booleans the token's state. A token can either be live (spendable == true && pending == false), in-flight (spendable == true && pending == true), or burned (spendable == false && pending == (true || false)).