Add unit tests for existing HelixClass functionality

[tmadlener]

A basic Catch2 setup with a small example of a unit test has been added with #31. As mentioned in #24 (comment) the mid-term goal is try and replace two possible approaches with only one. The first step would be to cover the existing HelixClass functionality with unittests in order to make it possible to more easily replace it's implementation. This purpose of this issue is to keep track of what has already been covered and what still needs to be covered.

Since there are several different ways to initialize the HelixClass each of them has to be tested (potentially with various combinations of position/reference point, momentum and charge). Afterwards the different getter functions should be checked whether they return the expected values.

Additionally, #24 lists a few quirks, which ideally should also be "documented" by introducing a test that covers the current behavior, even if that does not make a lot of sense. The main purpose of this effort is to make sure no existing behavior is broken by a future migration.

Short guide to writing tests

• Try to use the TEMPLATE_LIST_TEST_CASE of Catch2 to cover both HelixClass and HelixClass_double. If not possible, use HelixClass in a TEST_CASE since that seems to be more widespread.
• If there is a difference between expected behavior and actual behavior, there should be two versions of a test case with different labels "[expected]" and "[unexpected_current]", respectively. Most likely the [expected] case is currently failing, but this can be filtered. The important point is that [unexpected_current] documents current behavior and gives us an automatic indication when a change to HelixClass breaks the current behavior (and hopefully makes it behave as [expected]).
• If tests have common setup code, consider using SECTION for the different test cases, after the setup.

(incomplete) TODO list:

• Initialize_VP
• Initialize_BZ
• Initialize_Canonical