[feature]: custom Group Key API for minting

[jharveyb]

Related to #343 .

We have support for group keys that include tapscript trees, but no way for users to actually provide a tapscript tree root during the minting process. Specifically:

• Providing a specific internal key for a group key for an asset during minting.
• Providing a custom witness for group key membership in a batch when finalizing a batch.
• Storing the tapscript tree for future use (tracked in tapgarden/taprpc: permit providing a tapscript sibling hash for minting calls  #343)

For the first point, we'll need to add a new field to the Seedling and MintAssetRequest structs for custom group keys. We likely also want to mark these seedlings as using a custom group key, so that we require an external witness when finalizing the batch.

For the second point, we'll need to extend the FinalizeBatch call to accept a list of witnesses for each seedling. Otherwise we shouldn't have many changes wrt. creating the minting proofs.

The last point is being tracked in #343.

[jharveyb]

Depends on #768.

There are a few points in the minting flow where this feature could be exposed:

• AddSeedling call, when providing other details about the asset that will become the group anchor
• Finalize call, when specifying other batch-wide parameters like feerate
• A new call, Sign, to provide a witness for a group key in the batch

I'm in favor of the first option, as otherwise we have to specify the mapping between the provided witness and the asset seedlings.

Separately, there is the option to mandate that a tapscript tree is stored with tapd before minting begins (or least, with an RPC unrelated to minting). Then the tree could be referenced by root hash in minting-related calls.

More generally, right now we don't support an externally-managed key as the internal key for an asset group key. However, we also can't create a group key without an anchor asset. So we likely want to expand the AddSeedling call to be able to specify a custom internal key.

We'll also need more validation logic around group witnesses, to fail early for incorrect user-provided witnesses, but also to reject batch finalization if tapd can't produce a group witness directly (because a group internal key is externally managed).

[dstadulis]

During initial implementation investigation, @jharveyb uncovered, a few areas which necessary changes will need to be implemented. An corresponding issue to describe the necessary prerequisites before this issue is started is currently being written.
Roughly the prerequisite are:

• Reordering minter logic
• Exposing group key creation phases

[Roasbeef]

We'll also need more validation logic around group witnesses, to fail early for incorrect user-provided witnesses, but also to reject batch finalization if tapd can't produce a group witness directly (because a group internal key is externally managed).

IIRC, we can only actually validate the group witness once we know the true asset/ID, which right now is when we go to finalize (do the coin selection, etc) and obtain the genesis prev out. As a result, I think we're forced to either just accept all the witnesses in finalize, or accept it in AddSeedling, then only validate later on once we've done the necessary in selection. With the latter option, we could start to lock that genesis prev out sooner in the process, but need to make sure the lease is properly renwed.

[jharveyb]

Moved discussion on this requirement to #820.