Tests: Migrate to Catch 2.4.0+

[ax3l]

Migrate from Boost.Test to Catch2 for:

• compile time
• stability
• better native compiler support
• automated, modern code coverage and tooling on mainline repo
• no C++98 work-around legacy with a modern code base
• no long-term bugs (e.g. on OSX) and ominous valgrind issues
• triggers no warnings (as long as we didn't migrate to CMake's CUDA language feature)
• no dependencies (fully self-contained: just needs C++11 & a stdlib, easily ship-able when vendored)

Uses catch2 in a way where most implementation parts are only compiled once in a .cpp file for the main() and then linked against the test cases that pull only part of the header. Quite nifty and we could later on speed it up even more with PCHs for the tests, e.g. via cotire.

Related to #481.

• If you like, I can vendor a fixed single-header release into an alpaka third-party dir so one does not even need to pre-install Catch2 at all. I did this before in other libs and would add a switch that allows switching to an external dependency as well: Vendor Catch2: v2.5.0 #718
• If you like, we can enable some Catch2 fast-compile options on CI only, making runtime crashes a bit less detailed but one would likely debug local anyway.
• Compile times on AppVeyor look significantly improved (develop before) and Travis-CI (develop before) seems very well too, even including the initial docker image rebuild.

Debugger Options

In case you want to break into the debugger on failures, run an individual test executable with

gdb --args ./testName -a -b

as -h will show: -a aborts on the first error and -b breaks into the debugger.

Developers Install of Catch2

If we don't vendor a single-header version directly in Alpaka yet, which I would say we can do, install catch 2.4.0+ for yourself with user-level package managers. For example:

# (Linux/OSX)
spack install catch
spack load catch

or via

# (Win/Linux/OSX)
conda install -c schrodinger catch2

or via conan from bincrafters (Win/Linux/OSX)

or via vcpkg (Windows)

or via aur (Arch Linux)

or just quickly build it form source and extend your CMAKE_PREFIX_PATH

[ax3l]

Switched to Catch 2.4.0+ (instead of 2.3.0+) now since I saw in tests and changelog that runtime improved further in this release.

[ax3l]

The problem is likely caused by the way that we still manually add our compiler flags for C++ instead of using target properties. I "linked"/included the external library now more old school to avoid populating the std flags twice.

[ax3l]

Is it ok if we switch to a newer CMake, e.g. 3.11+ ? Improves handling of imported targets a lot and also (3.8+) adds better control over target properties/features.

[BenjaminW3]

After thinking about it some time I would prefer to include the testing framework within the project. I do not see any advantage of requiring the user to download the framework. Do you see any?
The user should still be able to set a different path to the test framework but the default should be the one included in the repo.
Should we use a submodule for this?

[ax3l]

Sure thing! Catch2 comes as a single header, either we check it in as such or download it on the fly with cmake. I am not a big fan of submodules for their usebility outside of pure meta repos.

[ax3l]

@BenjaminW3 can we please merge this before the other CI changes come in? I would like to avoid rebasing this a lot.
I can add a vendored catch2 header later on in a follow-up (I have the PR ready).

[ax3l]

Final CI compile-time comparison (similar to here): recent develop vs. PR with caches up
(3:40h vs. 3:03h).

Catch2 fast compile not yet activated and not yet vendored into our source.

[ax3l]

@BenjaminW3 hurray, CI finished :)

[ax3l]

@BenjaminW3 Catch 2.6.0 now contains a TEMPLATE_PRODUCT_TEST_CASE macro as we had it before :)