use std::to_char for formatting, fallback to constexpr formatting if needed
and the compiler supports it. std::to_char is available widley except for
floating point. Updated tests to expect the same value from runtime and
constexpr format tests.

std::to_char for floating point is the real edge case since it has poor
compiler support. Where it is supported it seems most implementations are
using a space-inefficient algorithm that can increase code size by about
1.2kB on ARM thumb architectures. This makes it unusable on embedded
platforms.

constexpr append changes to take into account the base of string conversion
so that pointers can be printed out in hex format and with padding zeros.

If the compiler doesn't support std::to_char forfloating point, then the
compile time option should disable use of std::to_char for all conversions.
This avoids mixing and matching implementations. Either append_constexpr
is used for all conversion, or std::to_char is used for all conversions.

This slightly complicates the testing as there is now a two variable truth
table as to the expected results when formatting -0.0.

On the 32-bit platforms in CI (windows and emscripten) large_int_t and
large_uint_t seem to alias each other in function definitions. Fix this by
using signed/unsigned concepts for the parameter. That way the incorrect
function will not be considered.

This required small bug fix in snitch::concepts. signed_integral and
unsigned_integral concepts need to check for sign and also make sure the
type is integral so that floating point or other types are not considered.

Explicit base template parameter on num_digits in set_precision function.
Also change all instances of `std::to_char` to the correct spelling
`std::to_chars`.