First-class support for sanitizers

[Morwenn]

Description
When running tests in continuous integration, it is rather common to use sanitizers (ubsan, asan, tsan, etc.). It would be nice if Catch2 reported errors as usual and logged the information that it generally logs when a test fails, such as the seed that was passed to the command line if any.

In libc++ at least, the sanitizers have a public API: https://github.com/llvm-mirror/compiler-rt/blob/release_36/include/sanitizer/common_interface_defs.h

It might be possible to do something with __sanitizer_set_death_callback or the other sanitizer-specific callbacks that can be found in the other headers in the same directory.

[FederAndInk]

This would be awesome 👍

[eiszapfen2000]

I did a hacky proof of concept for this, where I simply register a callback with __sanitizer_set_death_callback. The callback implementation itself does the same as the FatalConditionHandler, namely the following:
Catch::getCurrentContext().getResultCapture()->handleFatalErrorCondition( message );

This seems to be good enough to print the results of Catch2 before the process is terminated. Still, AFAICS FatalConditionHandler does register signal handlers, and even uses an alternate stack, but so do the sanitizers. The latter allow some degree of configuration with respect to signal handling, see https://github.com/google/sanitizers/wiki/SanitizerCommonFlags, handle_segv and friends. Still, Catch2 should interact with the sanitizers in an ok manner out of the box, without the users having to set magic sanitizer flags. I will investigate a bit further what actually happens during signal handling, and if the two actually get into each others hair.

From an implementation perspective, the right thing to do would probably to implement another FatalConditionHandler. That will cause some refactoring, since at the moment only a single instance of FatalConditionHandler is allowed to exist. But we would need to allow for two of them to exist alongside each other. Or we integrate the functionality into the existing FatalConditionHandler implementations. Which then leaves the case where both of those are disabled, but we still want to build with sanitizer support.
Additionally, CMake needs some magic to figure out if we are building Catch2 with any kind of sanitizer.