Provide Catch2's StringMaker specialization behind extra level of indirection

[horenmar]

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<T> -> 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.