This is the first step in preparation for:
https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450

Relates to
https://github.com/llvm/llvm-project/issues/119281#issuecomment-2699470459

This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.

Relates to: #119281

This bug is caused by the BigInt implementation failing to initialize
from errno. Explanation below, but the fix is a static cast to int.

The bug only shows up on risc-v 32 because of a chain of type-oddities:
1) Errno is provided by a struct with an implicit cast to int.
2) The printf parser uses an int128 to store the value of a conversion
   on systems with long double greater than double.
3) On systems without native int128 support we use our own BigInt
instead.

These combine such that if both long double and int128 exist (e.g. on
x86) there's no issue, errno is implicitly cast to int, which is
extended to int128. If long double is double (e.g. on arm32) then int64
is used in the printf parser, the implicit cast works, and there's no
issue. The only way this would come up is if the target has a proper
long double type, but not int128, which is the case for at least the
current risc-v 32 bot.

This patch adds the %m conversion to printf, which prints the
strerror(errno). Explanation of why is below, this patch also updates
the docs, tests, and build system to accomodate this.

The standard for syslog in posix specifies it uses the same format as
printf, but adds %m which prints the error message string for the
current value of errno. For ease of implementation, it's standard
practice for libc implementers to just add %m to printf instead of
creating a separate parser for syslog.

The previous change missed the second spot doing the same thing.

Bug: https://issues.fuchsia.dev/358196552

The previous change replaced INT_WIDTH with
cpp::numberic_limits<int>::digits, but these don't have the same
value.  While INT_WIDTH == UINT_WIDTH, not so for ::digits, so
use cpp::numberic_limits<unsigned int>::digits et al instead for
the intended effects.

Bug: https://issues.fuchsia.dev/358196552

This updates some code to consistently use cpp::numeric_limits,
the src/__support polyfill for std::numeric_limits, rather than
the C <limits.h> macros.  This is in keeping with the general
C++-oriented style in libc code, and also sidesteps issues about
the new C23 *_WIDTH macros that the compiler-provided header does
not define outside C23 mode.

Bug: https://issues.fuchsia.dev/358196552

Prevously, if INT_MIN was passed as a wildcard width to a printf
conversion the parser would attempt to negate it to get the positive
width (and set the left justify flag), but it would underflow and the
width would be treated as 0. This patch corrects the issue by instead
treating a width of INT_MIN as identical to -INT_MAX.

Also includes docs changes to explain this behavior and adding b to the
list of int conversions.