Update fee hysteresis

[endothermicdev]

This gets the channel opener to propose a higher feerate than what they would actually prefer to use (the minimum realistic fee.) This may address some feerate disagreements which lead to disconnects with peers due to non-exactly matching feerates as described in #6756. This may be due to differing mempool configuration, or fee estimation. Either way, some additional tolerance set by opener by default should improve the situation.

I'm not sure if we want this option exposed, but it seemed appropriate. The default is 5, which only covers rounding errors, but there are reports of CLN<->CLN fee disagreements by just 1sat per kw difference. Additional data may be useful to adjust this default.

Changelog-Added: Added option --commit-fee-offset to potentially reduce feerate update disagreements

[endothermicdev]

Corrected docs formatting and added a test.

[endothermicdev]

Looking at more logs and perhaps it would be better to apply this as a minimum offset above the min feerate rather than a constant offset from the nominal feerate. I would think times like this are where we run into issues:

2023-10-23T09:51:47.548Z DEBUG lightningd: update_feerates: feerate = 529, min=529, max=30740, penalty=529

However, that only seems to occur with certain mempool conditions. Later the same day, there's plenty of margin between the nominal feerate and the minimum acceptable:

2023-10-23T17:32:46.927Z DEBUG lightningd: update_feerates: feerate = 1791, min=557, max=24130, penalty=562

I have about 12 hours of time in the feerate == min regime over three weeks of data. I wonder if this is primarily when the feerate disconnect issues are occurring. If so, a minimum margin above the min acceptable feerate could be more appropriate.