We have a const for this, use it.

Internal change only.

Throughout the `amount::tests` module we use `sat` and `ssat` as aliases
to amount constructors but in on test we use them as `Denomination`
variables. To assist clarity and so we can introduce uniform usage of
the constructor aliases change the variable names to use the `den_`
prefix.

Internal change only, no logic changes.

We are about to start enforcing the MAX_MONEY invariant. Doing so will
change constructors to return an error type.

In preparation use the `_unchecked` constructor for all the consts.

Internal change only, no logic changes.

The unchecked-should-be-unsafe conversation is out of scope for this
patch. We want to bite off small chunks so the constructors are left as
they currently are - we are just doing the encapsulation here. This is
in preparation for enforcing the MAX_MONEY invariant which is not
currently enforced.

As per the sanity rules policy outline in:

 rust-bitcoin#4090

For both amount types create a private `encapsulate` module that
consists of exactly the type and a single constructor and a single
getter.

TL;DR For now, just use MAX_MONEY everywhere in this codebase.

This git log is long so that it can be discussed and _later_ changed if
needed. This is a trivial change, we do not need to bikeshed this at
this moment - by picking MAX_MONEY its a simple shell oneliner to change
it.

Weather we keep both constants or get rid of one is out of scope for
this patch. This patch is just about being uniform and suitably
expressive.

We have two amount constants MAX and MAX_MONEY that are equal. I believe
we should pick one and use it throughout the codebase to be uniform. I
am open to either option. There are arguments for both sides:

(Note please I have explicitly left out the argument "why do we even
have two consts" on both sides below for reasons noted above.)

Arguments for using MAX:

- MAX is more terse
- MAX is equally as expressive
- Future devs don't need to care about the difference because
  for them they will have always been the same

Arguments for using MAX_MONEY:

- MAX_MONEY is more explicit
- `::MAX` looks a lot like `u64::MAX` and for Bitcoin devs an amount is
  intrinsically a 64 byte unsigned integer.
- MAX was at one stage in `rust-bitcoin`s life equal to `u64::MAX` and
  now that has changed so the explicitness might be worth it.

[0] I don't personally trust my brain to not mix these up.

I royally botched the recent effort to make const amount constructors
use a smaller type. I left in an  unnecessary panic and forgot to do
both of them.

Note these function return values will change again very shortly when we
start enforcing the MAX_MONEY invariant. However the 64 to 32 bit change
is unrelated to that and is easier to review if done separately.

Whole bitcoin can non in any sane environment be greater than 21,000,000
which fits in 32 bits so we can take a 32 bit integer in the whole
bitcoin constructors without loss of utility. Doing so removes the
potential panic.

This is a breaking API change. We elect not to deprecate because we want
to keep the same function names.

Calculating the minimum non-dust fee currently panics if either the
script is really big or the dust fee rate is really big.

Harden the API by returning an `Option` instead of panicing.

Now that we have the `NumOpResult<Amount>` type that is used to show a
math calculation returned a valid amount we can use it when multiplying
weight and fee rates thus removing panics.

When we enforce the MAX_MONEY invariant these functions would require
the function signature changing - might as well just delete them.

Enforcing the MAX_MONEY invariant is quite involved because it means
multiple things:

- Constructing amounts is now fallible
- Converting from unsigned to signed is now infallible
- Taking the absolute value is now infallible
- Integer overflow is illuminated in various places

Details:

- Update from_sat to check the invariant
- Fix all docs including examples
- Use the unchecked constructor in test code
- Comment any other use of the unchecked constructor
- Deprecate unchecked_abs
- Fail serde (using the horrible string error variant)
- Try not to use the unchecked constructor in rustdocs, no need to encourage unsuspecting users to use it.
- Use ? in rustdoc examples (required by Rust API guidlines)
- Remove TryFrom<Amount> for SignedAmount because the conversion is now infallible. Add a From impl.
- Fix the arbitrary impls
- Maintain correct formatting
- Remove private check_max function as its no longer needed