Add argument to OpenChannel rpc to input UTXOs

[saubyk]

To simplify app development for coin selection on channel opens an additional argument should be added to the OpenChannel rpc. This argument should take an array of UTXOs which the application (user) passes. The processing logic should also include fee estimation, which enables complete UTXO consumption with no change output being generated.
Two scenarios to explain the requirement.

Scenario 1: User selects coins to use and specifies the amount to open the channel with. This can result in a change output being generated depending upon the amount in coins and fee rate chosen (essentially same as current functionality but with selected UTXOs)
The OpenChannel rpc will be called with:

• utxo argument
• amount
• fee rate (default or chosen by the user)

Scenario 2: User selects coins to use and indicates to use them whole. This should result in no change output.
The OpenChannel rpc will be called with:

• utxo argument
• fundmax flag as true
• fee rate (default or chosen by the user)

The scope of change includes:

• lncli
• grpc
• REST API

fundmax flag is introduced with the below pr:
#6903
Related issue:
#6949

[hieblmi]

@saubyk As mentioned in #6949 I'd like to take a shot at this issue.

One thought regarding Scenario 2.
Wouldn't it make sense to omit the fundmax flag and take the missing local_amt as indicator that the entirety of the --utxos is going towards the channel funding? This would also tie in with the current user experience when only specifying local_amt. We'd have:

• lncli openchannel --node_key=xxx --local_amt yyy -> spends entirety of local_amt
• lncli openchannel --node_key=xxx --utxos utxo1,utxo2,utxo3 -> implies to spend entirety of the 3 utxos
• lncli openchannel --node_key=xxx --utxos utxo1,utxo2,utxo3 --local_amt yyy -> spends yyy sats from the 3 utxos

[saubyk]

@hieblmi when it comes to providing options, my preference is always to be explicit rather than implicit. But I would let someone more qualified than I am on this, to chime in
cc: @guggero @Roasbeef

[guggero]

I agree with making things as explicit as possible. Otherwise it might happen that I forget --local_amt and my node just creates the largest channel it can. We could discuss using the value of -1 for --local_amt instead of an additional flag (at least on the command line, would probably still use the flag on the RPC), but not sure if that makes things any more clear.