Should `trixi_include` work recursively?

Trixi.jl example simulations contain a lot of duplicate code because many elixirs are almost identical.
In TrixiParticles.jl, we tried to avoid this by recursively calling trixi_include.
For example, we have a 3D version of a 2D example file, which looks like this:

using TrixiParticles

trixi_include(@__MODULE__,
              joinpath(examples_dir(), "fluid", "hydrostatic_water_column_2d.jl"),
              fluid_particle_spacing=0.05, initial_fluid_size=(1.0, 1.0, 0.9),
              tank_size=(1.0, 1.0, 1.2), acceleration=(0.0, 0.0, -9.81),
              smoothing_kernel=SchoenbergCubicSplineKernel{3}(), tspan=(0.0, 1.0),
              maxiters=10^5, fluid_density_calculator=ContinuityDensity(),
              clip_negative_pressure=false)

In this case, defining 3D fluid and tank sizes, 3D acceleration and a 3D kernel are necessary to make the simulation 3D.
The other kwargs fluid_particle_spacing, tspan, maxiters, fluid_density_calculator and clip_negative_pressure are defining the same values as in the 2D file. We only added them to be able to overwrite these assignments when including the 3D file:

trixi_include(file_3d, fluid_particle_spacing=0.02)

It would be very convenient to either

1. make trixi_include recursive,
2. add an option trixi_include(..., recursive = true), or
3. add a macro trixi_include_recursive.

Option 2 conflicts with overwriting assignments with the same name recursive.
Option 3 is a bit awkward.
Is there any reason against option 1?

I already implemented the logic for a recursive macro in #35.

Start with the trixi_include implementation and review the recursive-macro logic from #35. Use the cited 2D and 3D example files to check recursive inclusion and keyword overrides; done means the desired recursive behavior and its handling of conflicting assignments are defined and verified.