Refactor into separate lnproxy library and relay cmd

[lnproxy]

This should make it possible to build relays with bespoke rules as requested here: https://github.com/lnproxy/lnproxy/pull/24

Also separates out LND specific code to start the groundwork for adding support for cln or other implementations.

And also makes the code easier to reason about so that it wasn't too hard to add the experimental new amount_msat option suggested here: https://github.com/lnproxy/lnproxy/issues/19

This is a big refactor that introduces a lot of new code and I've only started testing. Do not run.

[blakejakopovic]

I've read through the code changes, and looks good. The approach seems sound as well - support multiple providers is valuable.

I don't know if this would be best as external logic, however supporting a lightning address as a provider would be very cool. Thinking about my ideas for use cases, if a user provides a lightning address as their payment method, then it can be used to generate invoices on the fly. It would also help make it more dynamic - but also more complex and failure prone, as the trade off.

[lnproxy]

Thank you! Yes, doing some final tests before merging.

The way I see it, there's two scenarios for the lightning address use case: 1) you run your own lnurl server on a domain you own: then you should use github.com/lnproxy/lnproxy-address 2) you use a trusted lightning address bridge (then an lnproxy address bridge would be better, I've been meaning to start running one using github.com/lnproxy/lnproxy-address just need a simple web frontend for it. Should be a different page then the main page though imo, since it's a different security model 3) you use a custodial wallet with lightning address support. Just use lnproxy when you withdraw to your own node or onchain using a reverse submarine swap service like boltz.exchange.