Provide Catch2's StringMaker specialization behind extra level of indirection

Right now, users cannot change how Catch2 stringifies types that it provides
`StringMaker` specializations for, such as `float` or `double`. This is due
to the stringification priority being `StringMaker` -> `operator<<` ->
fallbacks (`enum` handler, `range` handler, etc).

However, users often want to customize the output, e.g. the printed
precision for floating point types.

There are three ways to handle this, none of them particularly great.

* Provide customization knobs that the users can use to do what they want.
This option means that there is approximately infinity work to do, and
the customization options and desires can be mutually exclusive as well.
* Allow piecemeal disabling of each `StringMaker` specialization, e.g.
`CATCH_CONFIG_DISABLE_FLOAT_STRINGMAKER`, or `CATCH_CONFIG_DISABLE_DOUBLE_STRINGMAKER`.
This option adds **a ton** of configuration macros, which the users
are already bad at using -> it is common for users to build the impl.
library and their own tests with different configuration options, thus
breaking ODR.
* Hide Catch2-provided stringifiers behind another layer of indirection,
e.g. `StringMakerInternal`, used from the generic `StringMaker` template.
This allows the users to provide specialization of `StringMaker` and
have their specialization be used instead of ours. This is the best
technical approach, but has the disadvantage of causing potentially
significant compile time overhead.

Of these three options, only the last one is reasonable to implement,
**but** we need to measure the compile time overhead first, and decide
based on the final values.