The new implementation keeps track of found escape codes in a separate
vector, which has two advantages:
1) The handling of inputs without any escape codes is much faster. As
   this will be the case for majority of inputs, this should provide
   nice speedup all around.
2) We no longer mangle unrelated 0xFFs in the user-provided input.

Closes #3199

We generally do not even try to pretend to support more than plain ASCII,
because doing unicode in old C++ standards is a pain and a half. For
`toLower`, we used to wrap `std::tolower` with multiple casts to avoid UB,
but calling into it is relatively slow, and it tries to handle different
locales, which could cause unexpected results.

In addition, the new implementation is significantly faster, which helps
speed up the initial process bring up (as comparing tags, and thus test
cases is now faster).

The goal is to do the equivalent of clobbering memory, which forces
the compiler to keep side effects that are external to the benchmarked
function, while allowing it to optimize inside the benchmarked function.

E.g. this cannot be optimized away:
```cpp
BENCHMARK("foo") {
    global_count += 1;
};
```

while this can:
```cpp
BENCHMARK("bar") {
    size_t local_count = 0;
    for (size_t i = 0; i < 100; ++i) {
        local_count += 1;
    }
};
```

As the types and values sent into the writer are determined by Catch2,
I do not expect to actually need this support, but it is better to have
it and not be surprised in the future.

Closes #3176

The forward iteration logic already bounds-check for m_it != m_string->end(),
do the same for the backward iteration. The issue with the assert is
that the assert() might not be compiled in, and it is happening after
the dereference, so it was too late.

The old internals reached into the global hub to stash the allocation(s)
for enum value -> string value there, then kept around a potentially
invalid (in case the hub was cleaned up) reference into it, going through
whole bunch of virtual dispatch in the process.

The new internals just store the data in a static variable inside the
`StringMaker` specialization. This avoids potential lifetime issues,
avoids all virtual dispatch and (almost) reduces the include bloat in
the main header path.

The reason for (almost) there is that for full include correctness,
`EnumInfo` needs `<utility>` include for `std::pair`. However, this brings
in things like `std::relops`, because the std headers in C++ are dumb.
As this was not included before, and instead we relied on `std::pair`
existing in an internal stdlib header that we transitively included, the
full include size ends up bigger than before.