[WIP] Gizmo unification

@nnrw56 and @bvandenbroucke I need your opinion on this.

The idea here is to merge back Bert's GIZMO branch with the rest of the code. At the moment, the master code is able to switch smoothly between SPH implementations that only require two loops over neighbours. This switch is done simply by changing the define in const.h. Note that in the longer run, that should be done in the configure script. All the tasks are now agnostic of the hydro variation being used and simply call the right hydrodynamic functions, which are brought it at compile time via the file hydro.h.

Now, in the case of GIZMO, there are three loops over neighbours, meaning that the changes are not just restricted to runner.c but that more tasks have to be added.

In order to accommodate for this and to be more generic, I propose this modification which gives a framework to construct simply any number of loops over neighbours and the corresponding number of ghost tasks.

To be even more generic, I have created two kind of loops the "gather" loops (SPH terminology) which correspond to DOPAIR1 in swift and the "symmetric" loops corresponding to DOPAIR2. Any particle-based implementation would need N gather loop followed by M symmetric loops (Gadget-2: N=M=1, Gizmo: N=2, M=1). In principle, there exist cases with (N=0, M=1) but that would be a very bad implementation. I know one variant of SPH with (N=3, M=1) but none with M>1. As a consequence there will N+M-1 ghost tasks.

The first changes are:

• Create more generic names for the tasks.
• Create an array of these tasks for each cell.
• In 'runner_main()', implement a better way of switching between task subtypes.

Then comes the large bit.

In engine.c, we have have the function 'engine_maketask()' that does many things (ignoring gravity for now). It:

1. creates the first loop over neighbours
2. creates the ghosts
3. duplicates the first loop and create the dependencies.

So, as a first step, I have created sub-functions that correspond to these operations (same for gravity which corresponds to more or less empty functions).

I have then made the last two functions more generic. They will now create a generic number of tasks and create the correct number of ghosts and links for the given hydro scheme. This comes at the cost of having some pre-processor magic, which is a bit ugly but users willing to add more loops should quickly understand what is going on.

Note that the gizmo code in that branch is still an empty shell. It compiles but won't do anything. Let's focus on the architecture for now. Similarly, I have not done the corresponding work for the MPI tasks but it should be a straight-forward extension.

So, my question to both of you: What do you think of this way of doing things ? I really would like to bring Bert and GIZMO back in the picture before attacking gravity such that we can make it as generic as possible.