Add btcdctrl & generatetoaddress RPC

[linden]

This PR adds btcdctrl, a process controller wrapping btcd and providing typed configuration on par with the cli. Easing both production and testing with sensible defaults, making btcd incredibly easy to run programmatically.

btcdctrl embeds an RPC client, both to ensure btcd is ready when Start is called and to lower the amount of boilerplate needed to start and connect. This somewhat overlaps with integration/rpctest but covers a larger amount of use-cases while overall becoming a simpler implementation.

I've also added generatetoaddress, an RPC method which makes testing much simpler - as you no longer have to run an additional wallet for managing funds. I'm happy to split this into another PR, maintainers choice.

Note: integration/rpctest has a race condition with the port allocation, an empty port is found then only used somewhat late in the start-up procedure - has been an issue for me, in more complex testing environments when multiple processes are looking for empty ports at the same time. I've fixed that here by using port :0 which allows the OS to allocate a free port.

[Roasbeef]

This PR adds btcdctrl, a process controller wrapping btcd and providing typed configuration on par with the cli. Easing both production and testing with sensible defaults, making btcd incredibly easy to run programmatically.

What does this accomplish that btcctl or rpclient don't?

Can you explain the use case a bit more?

[Roasbeef]

Re the current approach to gain a free port: https://github.com/btcsuite/btcd/pull/2071/files#r1431328709

I think we can make this approach and the normal ":0" approach both available via a config.

[linden]

What does this accomplish that btcctl or rpclient don't?

Can you explain the use case a bit more?

@Roasbeef Sure, happy to. Our goal is to make running btcd simple, this materializes as a few things:

1. Configuration: Define the flags, makes it easy to avoid type errors and spelling mistakes as they'll be caught at compile-time.
2. Less Boilerplate: Ease the amount of boilerplate involved in starting up btcd and connecting via rpcclient, just 3 lines of code.
3. Standards: we've also implemented identical packages for lnd and tapd, making it easy to run all 3 at once under the same interface.

Our use cases so far have been, unit testing for our wallet and managing tapd/btcd/lnd in a single process in production (i.e. ensure btcd is ready before launching lnd).

Re the current approach to gain a free port: https://github.com/btcsuite/btcd/pull/2071/files#r1431328709

I think we can make this approach and the normal ":0" approach both available via a config.

I agree, although we'd have to listen on port :0 inside the process itself to avoid another process binding to it in the meantime. I'd opt to replace the current implementation, as I'm unable to think of an advantage of :0 - @guggero's comment is only relevant if we're binding to the port before the process.