Variables should be named according to the script semantic which is
an invariant with regards to generating a local or remote commitment
transaction.

I.e a broadcaster_htlc_key will always guard a HTLC to the party able
to broadcast the computed transactions whereas countersignatory_htlc_key
will guard HTLC to a countersignatory of the commitment transaction.

Previously most of variable fields relative to data belonging to
our node or counterparty were labeled "local"/"remote". It has been
deemed confusing with regards to transaction construction which is
always done from a "local" viewpoint, even if owner is our counterparty

To avoid reviewers confusion, rename counterparty_to_self_delay
to counteparty_selected_contest_delay, i.e the justice delay announced
by a channel counterparty restraining our transactions, and to_self_delay
to locally_selected_contest_delay, i.e the justice delay announced by us
restraining counterparty's transactions

We deviate from wider nomenclature by prefixing local data with a
locally_ extension due to the leak of this value in transactions/scripts
builder, where the confusion may happen.

Rename further AcceptChannelData to the new nomenclature.

A TxCreationKeys set represents the key which will be embedded in output
scripts of a party's commitment tx state. Among them there is a always
a key belonging to counter-party, the HTLC pubkey. To dissociate
strongly, prefix keys with broadcaster/countersignatory.

A revocation keypair is attributed to the broadcaster as it's used
to punish a fraudulent broadcast while minding that such keypair
derivation method will be always used by countersignatory as it's
its task to enforce punishement thanks to the release secret.

Transaction signing methods are changed from local_/remote_ prefix
to newer holder_/counterparty_ wihout any semantic changes.

Comment meaning of holder/counterparty

Diverse chan_utils cleanups

Cleanups post-cbindings merge

Fix misusage of holder_selected_contest_delay instead of counterparty
_selected_contest_delay in HolderCommitmentTransaction

Fix old payment_point comment