Remove Setup and setup:: from framework

One of the major issues preventing the merge of radio is that setup::Environment as well as setup::Trajectory and setup::Tracking have been directly used in the main CORSIKA framework and modules - this prevents a user from changing out to different environment (i.e. adding a refractive index for radio) or changing the tracking (i.e. from straight to leapfrog). This invalidates the whole motivation for making everything templated in the first place.

This MR is a first attempt at removing Setup* and setup::* from use in the framework so we can regain the flexibility of the templated design and allow radio to be merged in the next few weeks.

For most of the modules, this was trivial. The process methods were typically defined with template arguments in the .hpp file but then were specialized to setup::Trajectory (etc.) in the .inl for no reason. This MR fixes all of those so that everything is full templated (again) in both the .hpp and the .inl.

However, there was one major change that needs to be discussed as well as one blocking issues:

1. The media classes use mixin's with pure virtual methods that cannot have template arguments. Based upon the comments in the media and trajectory classes, I implemented a BaseTrajectory class that StraightTrajectory/CurvedTrajectory inherit from so any trajectory can be used in the media system. This allows the media system to be completely independent of the setup:: however it may introduce a virtual calling overhead - all of the trajectory types are known at compile-time so I'd hope that GCC/clang do the devirtualization at compile-time but I haven't verified that. Making this work without BaseTrajectory class may be possible with some major changes to the way we handle the environments (mixin's and template arguments are always a pain). @mreininghaus If you have ideas or recommendations, I'd love to hear from you otherwise this BaseTrajectory stuff works cleanly without any changes to the current media architecture. I'm guessing the comment about introducing a BaseTrajectory class was probably by you?
2. Cascade and SIBYLL's NuclearInteraction class need access to the type of the StackView which is currently a bit of a mess due to issues with Clang and GCC. See the comment here. The current method does not easily allow for changing the stack type except by modifying SetupStack.hpp which is not a viable option (a user shouldn't need to modify the core library to do this especially once we started distributing system package). @rulrich @mreininghaus Do you have any thoughts on how we can rearchitect this to make it easy to choose a stack without the ifdef mess in SetupStack.hpp.

I'll have time to finish this MR this week if we can come to a conclusion about to proceed with 1) and 2).