Fix bugs related to the introduction of apertures and lost-particle state

[martinschwinzerl]

Summary: Addresses a bug found by @hannes-bartosik concerning the proper treatment of lost-particles in lattices with Apertures. The required changes to the logic in the tracking functions triggered a big refactoring and (hopefully) simplification drive that also brought the OpenCL implementation more in line with the CUDA and CPU tracking options.

Details:

• Aperatures (NS(LimitRect), NS(LimitEllipse)) should work properly with respect to the lost particle state. Thank you to @aoeftiger for his help in testing this already on CUDA!
• The global aperture check is no longer performed inside the NS(Drift) and NS(DriftExact) maps
• The global aperture check is still by default performed for each NS(Drift), NS(DriftExact) but can be disabled at compile time. This addresses issue #74
• Replaces the sixtracklib/common/track.h function with a new implementation in sixtracklib/common/track/track.h -> it contains a lot fewer functions and should be much simplier to understand
• Introduces common implementations for "optimized" and non-optimized tracking kernels that are shared across Cuda, OpenCL and the CPU. Cf. sixtracklib/common/track/track_kernel_impl.h and sixtracklib/common/track_kernel_opt_impl,h
• Adds common kernel implementations for assigning output buffer addresses to elem-by-elem configs and beam monitors
• Fixes a race condition concerning the initialization of the elem-by-elem configuration on OpenCL
• Removes the single-turn tracking API still present in the OpenCl -> use track_line for the full lattice plus the end of turn flag for similar functionality
• Transitions the OpenCL "controller" closer towards unification with the Cuda controller -> this changes the API
• Transitions the OpenCL track_job internally closer towards unification with the "new" track jobs for Cuda and CPU
• Introduces the new snake_case API also for C++ (rather than camelCase used so far) in preparation of facilitating code-generation in the future (i.e. functions in C++, Python and C should eventually really have the same name)
• Further progress in cosmetic changes and clean-ups, especially on the CMake side of things

Open issues:

• There is a very weird Heisenbug in the Elem-by-Elem Tracking implementation affecting only OpenCL / AMD GPUs (verified with Radeon VI and RX 560, potentially also affects ROCm but I have to do some additional testing there). It only occurs in the so called "optimized" track (which uses thread-local storage for the particles) and stops occuring once enough print statement for debugging are present in the kernel - very very confusing.

For the meantime, I disabled the optimized tracking for AMD OpenCL platforms, any hints or suggestions on the cause of the issue would be highly appreciated!

Notes:

• C/C++ API calls especially to the OpenCL controller and track jobs have changed. Please update any use of them
• Expect most other user-facing C/C++ to be changed to the snake_case version to facilitate code-generation in the near future
• The "debug mode" of the controllers and track jobs is about to be mostly relegated to handling different compiler / optimization options and is expected to no longer provide dedicated versions of some kernels with more error handling. The practice has shown that they don't bring the intended benefits and contribute a lot of lines of code -> I would like to get rid of them. Comments and complaintes welcome!
• Disabling the global aperture check can currently only be reliably performed for the CPU variants via the Setting in the Settings.cmake file. This will be exposed as a "Kernel Variant" together with Optimized / non-optimized, Beam-Beam / Space Charge enabled, etc. kernel builds. Please ask if you want to experiment with this before the proper API lands

[martinschwinzerl]

This PR seems to be quite complete now. We've added backports of the OpenCL download functionality and the SIXTRACKLIB_DEVICES support to allow testing on an equal footing with the current master, and removed the recursive faculty calculation in the Multipole datatype of the python SixTrackLib with a call to scipy.special.faculties.

If further testing of the updated library does not reveal new problems, it can be merged (after fixing the conflicts with current master mostly arising from the changed APIs of the OpenCL track job and context)