chainntnfs: refactor fundamental interfaces uses type params to reduce duplication

[Roasbeef]

Is your feature request related to a problem? Please describe.

Today the chainntnfs supports 3 backends: btcd, neutrino, and bitcoind. Each of the backends live in their own pacakage, but unfortunately have a ton of duplication across them all. We now have the TxNotifier that encapsulates a lot of the notification related book keeping, however each pacakge still has a lot of dpluication, eg:

• btcd:

  lnd/chainntnfs/btcdnotify/btcd.go

  Lines 561 to 566 in f9d4600

  	// historicalConfDetails looks up whether a confirmation request (txid/output
  	// script) has already been included in a block in the active chain and, if so,
  	// returns details about said block.
  	func (b *BtcdNotifier) historicalConfDetails(confRequest chainntnfs.ConfRequest,
  	startHeight, endHeight uint32) (*chainntnfs.TxConfirmation,
  	chainntnfs.TxConfStatus, error) {

• bitcoind:

  lnd/chainntnfs/bitcoindnotify/bitcoind.go

  Lines 512 to 518 in f9d4600

  	// historicalConfDetails looks up whether a confirmation request (txid/output
  	// script) has already been included in a block in the active chain and, if so,
  	// returns details about said block.
  	func (b *BitcoindNotifier) historicalConfDetails(confRequest chainntnfs.ConfRequest,
  	startHeight, endHeight uint32) (*chainntnfs.TxConfirmation,
  	chainntnfs.TxConfStatus, error) {

The code here is nearly identical.

We should refactor this area more to eliminate the duplication, as small changes now need to touch 3+ files for no good reason.

Describe the solution you'd like

Create a new interfaces to encapsulate over the backend differences. As an example, for btcd we can use the RPC client directly, but for bitcoind we use the btcwallet wrapper for them.

With this, we can then create a new unified Notifier[B ChainBackend] interface that uses type params to instantiate a version dependent on the new backend type/interface. May be the case the type param also actually isn't needed for this specific interface, but some of the areas where we end up consuming values from a channel wants type params more.