calc_boundary_flux! is allocating for HOHQMesh and DGMulti

[DanielDoehring]

While tackling #1664 I observed that

Trixi.jl/src/solvers/dgmulti/dg.jl

Lines 468 to 480 in bb60b5d

	# "lispy tuple programming" instead of for loop for type stability
	function calc_boundary_flux!(cache, t, boundary_conditions, mesh,
	have_nonconservative_terms, equations, dg::DGMulti)
	# peel off first boundary condition
	calc_single_boundary_flux!(cache, t, first(boundary_conditions),
	first(keys(boundary_conditions)),
	mesh, have_nonconservative_terms, equations, dg)
	# recurse on the remainder of the boundary conditions
	calc_boundary_flux!(cache, t, Base.tail(boundary_conditions),
	mesh, have_nonconservative_terms, equations, dg)
	end

is allocating for the dgmulti_2d/elixir_euler_hohqmesh.jl example, see e.g. https://github.com/trixi-framework/Trixi.jl/actions/runs/6574426931/job/17859451194#step:7:8803

I could not figure out why that is, also the specialization

# "lispy tuple programming" instead of for loop for type stability
function calc_boundary_flux!(cache, t, boundary_conditions::BC, mesh,
                             have_nonconservative_terms, equations, dg::DGMulti) where {BC}

    # peel off first boundary condition
    calc_single_boundary_flux!(cache, t, first(boundary_conditions),
                               first(keys(boundary_conditions)),
                               mesh, have_nonconservative_terms, equations, dg)

    # recurse on the remainder of the boundary conditions
    calc_boundary_flux!(cache, t, Base.tail(boundary_conditions),
                        mesh, have_nonconservative_terms, equations, dg)
end

does not solve the issue.

[jlchan]

Awesome! Glad #1695 fixes it