btc: more sensible bond fee buffer

[chappjc]

When used for computing the bond fee buffer, the "fee rate limit" makes
an extremely high fee rate buffer, which makes BTC bonds impractical.
This change:
- switches to using a dynamic fee rate with the configured fallback rate
  for both ReserveBondFunds and BondsFeeBuffer, where the former is
  used as the requirement for the frontend to proceed with registration
- uses the exported BondsFeeBuffer method when automatically creating
  the "extra" split output in certain order funding edge cases instead
  of a buffer based on the high limit.
- tweaks the bond tx input count to be slightly less conservative, going
  from 12 -> 8 possible inputs

The motivation for these changes is that using the wallet's configured
fee rate limit creates extremely high fee buffers, whereas we have
defined the "fallback" fee rate to be a reasonable fallback where a
current estimate is not available, which also happens to be applicable
to a *future* fee rate.

Further, this is a buffer and precision is not critical, but turning
users away from on-boarding is a major issue.  The right approach
is to base reserves on a padded estimate based on current rates,
not the swap fee rate limit.

Finally, given this softening of the reserves amount, no adjustment to
the enforced bond reserves in Reconfigure is done since we are now
using current rates as a hit of future rates.

Padding of this fee buffer already comes from:
- planning for a lot of inputs
- 4 parallel bond tracks
- the exported BondsFeeBuffer method using double the provided fee rate

Even if fee rates skyrocket, and the reserves become insufficient for
bond renewal, the user will still post bond if their balance allows, and
they may deposit some nominal additional amount to cover any such
deficit.

Before

(that's about 1500 USD, not sensible)

After

(that's <100 USD, or 2x the bond amount plus realistic fees)

[chappjc]

Back to not touching the bond reserves on wallet config change.

[buck54321]

How about a feeSuggestion uint64 argument to BondsFeeBuffer and ReserveBondFunds so that wallets without external API enabled will still get realistic values, even if the user has misconfigured their fallback rate?

[chappjc]

Refactored so that the BondsFeeBuffer and ReserveBondFunds methods now take a fee rate. If zero, those methods will try to get an internal rate or use the configured fallback.

[chappjc]

Will push a refactor shortly. Sorry if there are reviews in progress.

[chappjc]

OK, despite now using a live fee estimate as the basis for the bonds fee buffer, the wallet wait form should not be fickle with respect to the required amount to proceed. Also, the (*Core).PostBond method now has an optional fee buffer field in it's parameter struct so that the fee buffer that was planned for will be used when setting the reserves.

Last commit fixes an existing js bug where the wallet wait form would be skipped entirely if the wallet existed and had at least one bond amount in available balance (not the required double plus fee buffer).