Smoothing lengths for sinks

This merge request adds all the required functionality for sinks to have adaptive smoothing lengths and proper SPH kernels, bringing them into line with other SWIFT particles. It's quite a big MR, so here are the main things for you to know about. The changes must extend beyond just the ghost and renaming of variables.

Changes to the sink density ghost and renaming of variables throughout code

This is where the majority of the work has been done. The new sink density ghost has been lifted almost verbatim from the BHs and does all the smoothing length iteration and checking that we need. Variables like r, r_max have been renamed to h, h_max throughout the code as required.

For consistency with the other particles, we now always assume we're dealing with a smoothing length and not a cutoff radius. Factors of kernel_gamma have now been added or removed throughout the codebase as necessary. One can still use a fixed cutoff in GEAR, however - more on this below.

The sink property use_fixed_r_cut is now a mandatory property for all sink models, and as you might expect, it flags whether we're using a fixed cutoff radius. If this flag is 0, the sink density ghost will not bother calculating/updating the smoothing length. The cutoff radius is now not a required sink property.

Sink SUBSET interaction tasks implemented

When particles are iterating on their smoothing lengths, they make use of "subset" density interactions to save time. These were not implemented for sinks, so I've added them - again lifting entirely from the BH tasks. @Roduit you may need to take this into account when implementing MPI.

Updates to GEAR to retain old functionality but allow variable cutoff radii

The GEAR model now contains all the infrastructure required for the sinks to have a variable smoothing length and cutoff radius. If the cutoff radius is specified in the paramfile, the new approach is to set the smoothing length sink->h = r_cut_fixed/kernel_gamma. This is then kept fixed throughout the simulation. If the cutoff is not specified, the smoothing length is calculated in the normal way. The new mandatory use_fixed_r_cut flag tells us which behaviour to use.

In all the GEAR calculations, we then use h*kernel_gamma as the cutoff radius, regardless of whether or not h is fixed. This retains the old behaviour of the model, if a cutoff radius is specified in the paramfile.

We determine whether to use a fixed cutoff in sink_properties.h at the time the properties are read in. The fixed cutoff is set (or not) for a given sink particle when it forms, in sink_copy_properties.

Updates to runner_iact_sink and runner_iact_nonsym_sink

These interactions (which check for sink proximity in GEAR) previously took in the cutoff radius as an input. Now that the cutoff radius is not a mandatory property of sinks, this needed updating as it is used in all models. The function now takes the whole sink_properties struct, from which the cutoff radius can be retrieved. This is consistent with many of the other interactions and is a minimal change to the code. This function is called many times in runner_doiact_functions_hydro.h, which has been updated to reflect this change.

Basic sink model with Bondi-Hoyle accretion

This MR includes a new "Basic" model for sink accretion, as we discussed on our call, which makes use of the new kernels for sinks. Its primary feature is that it is extremely bare-bones - it has no dependencies on other subgrid physics from GEAR or otherwise. It also ONLY does Bondi-Hoyle accretion - there is no mechanism for sink formation, or for star formation from sinks. It does do sink-sink mergers, in a slightly streamlined version of what GEAR does.

We could include this model with this merge, or separate it off into a separate MR, perhaps with a test case included. Let me know what you would prefer.

Sink brute-force density checks

I've implemented the brute-force density check that was already present for particles and stars, in the new file sink.c and with changes to engine.c and the sink models themselves. These are activated with the --enable-sink-density-checks compile option.

doc/RTD/source/SubgridModels/Basic/index.rst

@@ -5,6 +5,25 @@
 Basic model (others)
 ====================
 
+Sinks: Simple Bondi-Hoyle accretion
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``Basic`` sink model provides a foundation on which new sink implementations could be built. It includes a prescription for Bondi-Hoyle gas accretion, and a method for sink-sink mergers that is a slightly simplified version of the implementation used in GEAR.
+
+No other physics is implemented for this model. Sinks cannot form - to use this model, sink particles must already be present in the initial conditions. They also cannot spawn stars from the gas they accrete.
+
+Bondi-Hoyle accretion can be done in one of two ways:
+
+ * Gas particles within the sink's kernel are stochastically swallowed entirely, with a probability set by the Bondi-Hoyle rate. Specifically, the probability is set by the current difference between the sink's subgrid mass (determined by the accretion rate) and its dynamical mass (which tracks the number of particles/sinks actually swallowed). This mode is equivalent to the EAGLE black hole accretion model.
+ * Gas particles within the sink's kernel are "nibbled" down to some minimal mass, which can be specified by the user. This method is equivalent to the black hole accretion model of Bahe et al. 2022.
+
+This model has only two parameters that must be specified in your parameter ``yml`` file:
+
+ * ``BasicSink:use_nibbling``: determines whether accretion is done by "nibbling" or by swallowing outright.
+ * ``BasicSink:min_gas_mass_for_nibbling_Msun``: if using "nibbling", the minimum mass to which gas particles can be nibbled. A good default is half the original particle mass.
+
+For an even more bare-bones starting point, the ``Default`` sink model contains no physics at all, and is a totally blank canvas on which to build your sink model.
+
 
 Cooling: Analytic models
 ~~~~~~~~~~~~~~~~~~~~~~~~