Consider providing a method to disable global StringMakers

**Description**
When using Catch with another framework that already has a comprehensive idea of how to perform stringification, it would be nice to be able to specialize StringMaker to make use of that. Unfortunately, attempting to do so causes clashes with various other specializations provided by Catch itself.

It's fairly trivial to patch these out, but it would be nice to not have to do that.

**Additional context**
(I'm using catch 2.12.4 if that matters)

Part of the reason I am choosing to go this way is because a library I use is polluting the global namespace with something like this:

class Foo { template Foo(const T&); };
std::ostream& operator<<(std::ostream&, const Foo&);

Which causes Catch to try to send everything that is not explicitly covered by StringMaker to that operator<< even though, naturally, Foo cannot actually be created from everything. This cannot be fixed due to backwards compatibility concerns.

But in addition, since I already have a set of comprehensive stringification covering pretty much every type I'd ever need, it'd be nice to not have to write them a second time (using either ostream, or StringMaker) by hand.

My attempt to do this was, roughly:

template
std::string mystringify(const T& val); // implementation irrelevant, but suffice to say, it will work for everything I care about

namespace Catch
{
template
struct StringMaker {
inline static std::string convert(const T& value)
{ return mystringify(value); }
};
}

But unfortunately, this fails because some of my types provide a begin() and end(), which gives me compile errors for ambiguous instantiations (against struct StringMaker::value && !::Catch::Detail::IsStreamInsertable::value>::type).

My "solution" for the time being has been to ifdef out pretty much all the StringMakers other than my own.

It might be that I am missing something supremely obvious here, I haven't really put much thought into this because I want to get on with the more "important" job of writing tests, rather than plumbing the test framework to be able to do so - please let me know if that is the case.