expose command line option for app to connect to remote lnd node

[Roasbeef]

IIUC, there are two ways to use the application atm:

1. Fully integrate lnd+neutrino mode. This spins up lnd locally, passing the arguments to use the neutrino mode, and also connect to the initial bootstrap cluster (on testnet). We primarily do releases to provide users with updated versions for this mode. Atm, this mode is testnet only, as there're some backend items within lnd and neutrino that need to be updated.
2. Using the command line, connect to a remote btcd, with and lnd instance spun up locally. IIRC, this was added earlier on before testnet neutrino's sync was stable enough. To my knowledge, not many users use this mode currently, as a testnet full node is pretty light, and option Uncaught Error: Module version mismatch. Expected 50, got 48. #1 now exists.

I propose we add a 3rd operating mode: application running locally that connects to a remote lnd node. This provide a simple interface for all existing routing node operators (casual and hardcore) that use lnd today. The current testnet deployment while functional is a bit limiting, as testnet is simply less "fun" than mainnet. Additionally, many services (regrettably) seem to now be skipping testnet all together and jumping directly to mainnet. By allowing users to connect to their existing routing nodes, we're able to get some feedback from a slightly more advanced group (some set up to get this working compared to a double click) and also start to grow the user base of the application ahead of the full desktop and then later neutrino releases.

The command+arguments on the cli would look something like:

./Lightning.app --remote_connect=true --bitcoin.mainnet --rpcserver=roasbeef.computer:9099 --adminmacaroon=localpath.macaroon --tlscert=localpath.cert

The items we need are:

• mainnet vs testnet
• where to hit the rpc server at (will no longer be local host)
• the admin macaroon (will no longer read from disk, will be specified in hex form)
• the cert so we can connect to the remote lnd

In order for this to work for the users, they may need to generate a new rpc.cert that allows connections from sources other than localhost. They can do this with the --tlsextraip argument. They'll also need to modify --rpclisten to be 0.0.0.0 instead of localhost

With the above implemented, rather than spinning up a local lnd instance locally, the app instead attempts to connect out to the remote lnd instance (if those args are set on the command line). This would be the only functional change in this mode other than the lack of logs (as we don't get the logs over RPC).