WIP: Initial implementation of (draft) radio emission interface class.

This is a very WIP merge request (primarily intended to start some discussion) regarding the implementation of radio emission (and is still very incomplete). I recently started implementing the ZHS radio-emission algorithm for CORSIKA8 - I have extracted the current interface and included it in this MR. I want to present some of my design motivation and thoughts below and would appreciate feedback from anyone interested in contributing. I think it would be great if we could have this discussion now so we can present a clear roadmap at the upcoming C8 workshop and solicit wider feedback.

I have broken out these discussions into points below:

1. There will certainly be more than one radio implementation developed for C8 for algorithmic (ZHS vs. endpoint), computational (CPU vs. GPU), and physics reasons (w/ and w/o refractive raytracing, optional multi-path reflection modeling, sudden death pulses, etc.). However, many of these implementations will share a lot common reusable code (adding+deleting antennas, configuration file reading, writing waveform output files, etc.) and may only differ in the actual calculation of the field. We need to provide a clear and straightforward method for creating new radio implementations that can easily reuse this infrastructure (implementations that differ significantly from the interface can of course implement a new radio process from scratch). I think, as a framework, we must strongly encourage reusing as much code as possible between radio implementations.
2. To work towards the above, this MR implements a basic CRTP RadioEmission<RadioImpl> interface class for concrete RadioImpl-ementations and a CRTP Antenna<AntennaImpl> for interfacing with antenna instances that may potentially have different internal constraints. The RadioEmission<> is currently a ContinuousProcess so that we can utilize the existing infrastructure but there are API challenges with this arrangement that can be discussed in detail later. Users would then instantiate RadioEmission<ZHS<CPU>>, RadioEmission<Endpoint>, RadioEmission<ZHS<GPU>> (as arbitrary examples).
3. To successfully support this wide variety of implementations, I think it's important to standardize (where possible) on configuration file formats (i.e. antenna lists) and on output waveform formats so that users can change radio implementations without modifying their analysis software. Reading and writing of these files can be implemented as part of the interface above or potentially as C++ mixins. My opinion would be to use a common high-level file format (HDF5, Parquet, etc.) for the output waveform file as opposed to a custom binary format but that is something that should be discussed.

I'm aware of two major blocking issues on the radio front:

1. EM cascade modelling (which is a much broader issues than just radio). However, the implementation of the radio emission can proceed before we have validated EM cascades - there exist hadronic-only versions of ZHAires that could be used to help (partially) validate the CORSIKA8 radio implementation while the EM models are being developed. A working radio implementation (validated using hadronic-only ZHAireS or hadronic-only CoREAS?) could potentially even assist in the validation of the EM cascades.
2. Magnetic field modeling as part of the CORSIKA8 environment. I think this is a relatively straightforward process that could be done in two steps: a) implementing magnetic fields for corsika::environments and b) implementation of the Lorentz force (using RK4 or sim.) as part of the particle step routines. I'm happy to work on this and will create a separate issue where we can discuss this in more detail.

Any and all comments are welcome and encouraged! I would like to send around some preliminary slides for the radio session of the workshop, based on this discussion, sometime next week for further comments.

Do you have any thoughts/comments @huege?