[Epic] funding+contractcourt+lnwallet: implement an initial version of Simple Taproot Channels

[Roasbeef]

This is a master tracking issue which tracks the implementation of the new-ish Simple Taproot Channels proposal: https://github.com/lightning/bolts/pull/995.

Things are still a bit influx, but there's some fundamental-ish work that can be started related to the funding outputs, and also the internal logic to perform tapscript spends.

One open question still is: can we actually get away with storing zero nonces on disk? Consider that today, we have 2 signatures, so we keep the remote party's on disk, then sign at broadcast time when we want to go on chain. This is nice from a security perspective, as with just the channeldb (no keys) you can't try to broadcast some revoked state. In this case of musig2, there're two logical signatures, which are then combined into a single signature to broadcast. The PartialSigAgg (sig combination) routine of the musig2 draft only needs the final public nonce, the challenge hash, and the tweak accumulator, all of which are "safe" inputs. However to sign we need our secret nonce, which means we may need to keep it around longer, potentially encrypted within the wallet along side the other imported public keys.

[Roasbeef]

So all the major PRs are now up: https://github.com/lightningnetwork/lnd/labels/taproot.

Right now all the PRs are built against either master, or the other set of dependent PRs. This makes it hard for reviewers to look at just the latest commits, as there're 50 other commits unrelated to that core PR that are still displayed. Also now that we're in the rc cycle for a major release, we don't necessarily want to be merging in unused/untested taproot logic either.

To streamline things a bit, I propose that we switch to a longer lived feature branch approach for the remaining development cycle for taproot chans. Rather than 9 PRs which all include the commits of the prior one and target a merge against master. We'd switch to the following approach:

• A new unified feature branch simple-taproot-chans.
  • This is branched off of 0.16 as is (master today).
    • Each PR in the series is now pushed to a new branch on the origin repo (Github).
    • All the PRs are updated to target merging into the "next lowest" (by PR part series) sub feature branch.
    • As each of the PRs are ready (normal CI checks, etc), we merge them into the master feature branch (simple-taproot-chans)
    • Once all the sub PRs are merged into that master feature branch, we'd then make a single PR to merge it back into master as we know it today.

With the above approach, it should be easier to reviewers to look at just the changes relevant to their assigned PR. It also enables us to be more non-blocking, as we don't need to halt all merges during the rc phase of another release. It'll also make things easier for me, as rather than continually rebase ontop of master and all the dependent PRs, I can just target the dependent feature branch instead. As long as people are using a sane git client (one with a tree based commit view) it shouldn't be too hard to follow.