`FormatOptions` was a workaround to support arbitrary `fmt::Write` in
legacy API. That API is now removed so `FormatOptions` is no longer
needed because we can just accept `Formatter` and pull the options from
itself.

This commit removes the struct and the argument from `fmt_satoshi_in`,
changing `f` from `fmt::Write` to `fmt:: Formatter`.

We'd like to improve formatting of other types to support decimals. To
avoid code duplication, this commit does part of the change: simple move
to a separate file with appropriate plumbing.

This is still not fully general but it's simpler to review.

Before a decimal number is displayed it is normalized to not end with 0
unless it's 0. This was performed in amount formatting but it applies to
all numbers. The change was intentionally split up to make review
easier.

This moves the computation from a single branch and makes it
unconditional. This is valid because other branches keep
`num_after_decimal_point` as 0 and the condition in the moved code does
0 check, returning 0 which is the valid value for the other branches.

When displaying a decimal number rounding may be required to satisfy
`precision` field on formatter. This implies rounding is also a general
concept, not tied to `Amount` and needs to be moved to decimal as well.

This commit moves rounding but because decimal accepts numbers before
and after decimal point it needs to be modified a bit to account for the
possibility that the number before decimal point increases because of
rounding. E.g. 0.999 Rounded to two decimal places is 1.00.

So far `FeeRate` had very sketchy implementation that relied on
`alternate` to select the unit, which was surprising and limiting.
Also the sat/vB implementation computed ceiling but also added `.00`
which looked like the value was exact. Further, the unit was always
shown in case of sat/vB and never shown in case of sat/kwu.

To fix it, this commit adds a new `Display` type similar to the one in
`amount` which can be used to tweak how it's displayed. Because
`FeeRate` so far supports multiple rounding modes the support of these
modes was added to the `Decimal` type and the `Decimal` type was used to
implement `Display`. The unit is displayed by default to avoid confusion
and can be hidden with a method call.

This doesn't modify the `Display` impl yet because it's more complicated
and easier to review separately.

As mentioned in previous commit, the `Display` impl was inconsistent and
problematic in multiple ways. The previous commit introduced an
alternative API that can tweak the formatting but didn't touch the
`Display` impl. This one does but to do that `FromStr` had to be changed
as well.

This changes the `Display` impl to always show the unit and also
delegates existing `sat/vB` code to the newly-added API, so that decimal
formatting is more sensible. This change is very obvious in output and
breaks parsing which is intended. So to ensure our roundtrip tests keep
working this also modifies `FromStr` to require the unit similarly to
how `Amount` requires denomination.

For simplicity, the code currently doesn't support sat/vB parsing but
does detect the attempt and reports the error properly. This can be
added later.

The comment claimed that, as opposed to floats in `core`, the display
implementation doesn't support lower precision. This was true in the
past but it was later changed to support it making the comment stale.

When a number has no decimals, setting the value and rounding doesn't
make sense since they will not be used. Conversely, if the number after
decimal point is 0 then setting number of decimals makes no sense since
it would be normalized to 0. So far the code dealing with these cases
was setting useless values to those fields.

This change refactors the code to use a single filed which is an
`Option` to represent the number after decimal point being present or
not. So either all values need to be provided or none of them. To
improve clarity, `NonZero` integers are used to enforce that the values
are not zero.

Since the code internally transforms the value another, similar type is
used. But this time it's an enum to represent the possibility that
there's no actual number and it's just trailing zeros requested by
formatter.

Using `NonZero` also uncovered an API edge case: setting inconsistent
values to those fields can lead to broken behavior. I don't see a
straightforward solution, and the API is internal, so keeping it as
panic seems reasonable.

During the refactor I also noticed overflow when consumer entered
absurdly large precision was not handled. Since it only affects padding
and the resulting number would be larger than any possible `width`
provided by the formatter the correct fix is to use `saturating_add`.
That way the ("incorrectly") computed number width will be larger or
equal to `width` leading to zero padding and if it was possible to
compute larger number width it'd still be larger than `width` leading to
zero padding.