anchors: follow up changes after initial zero fee anchors merge

[Roasbeef]

Fixup changes:

• features: make anchor zero fee explicitly dependent on static key
• re-order section explaining new HTLC output trimming

[t-bast]

re-order section explaining new HTLC output trimming

I don't see this one?

Could you also fix the tiny typo referenced here: https://github.com/lightningnetwork/lightning-rfc/pull/824/files#r698775217 ?

[rustyrussell]

We can fix this too, I just noticed:

BOLT #2:

 A receiving node:
  - if `option_static_remotekey` or `option_anchors` applies to the commitment transaction:
    - if `next_revocation_number` is greater than expected above, AND

The "or option_anchors" is now redundant...

[rustyrussell]

This too...:

	 * The sending node:
	 *   - MUST set `next_commitment_number` to the commitment number
	 *     of the next `commitment_signed` it expects to receive.
	 *   - MUST set `next_revocation_number` to the commitment number
	 *     of the next `revoke_and_ack` message it expects to receive.
	 *   - if `option_static_remotekey` or `option_anchors` applies to the commitment transaction:

[ariard]

See my comment here : https://github.com/lightningnetwork/lightning-rfc/pull/824/files#r698781292. At least might be good to precise combination should only be done with transactions within the same "safety" domain (equal or 0-value nLocktime, non-third-party spendable scripts, SIGHASH_ALL lockdown of inputs, ?). Otherwise it's left to implementer wisdom which have proven tricky to get right in this area.

[t-bast]

@Roasbeef any progress on this PR? I can take it over if you don't have time, let me know.

[Roasbeef]

Pushed up extra commits addressing Rusty's comment.

re-order section explaining new HTLC output trimming

TBH, it's been so long with this PR that I forgot what I was going to do here...

[t-bast]

ACK 779f366