Address type piracy related SummationByPartsOperators.jl and StartUpDG.jl

[jlchan]

          I am not 100% sure if we want or need this, but adding Aqua tests seemed like not such a big issue to add. Also, testing time is hardly affected (<1 min). There are a lot of imho false-positive method ambiguities. There's also a legit piracy warning, thanks to buccaneer-in-chief @jlchan. I added an exception such that tests pass, but we could also think about moving [the relevant function](https://github.com/trixi-framework/Trixi.jl/blob/main/src/solvers/dgmulti/sbp.jl#L457-L475) to StartUpDG.

Originally posted by @sloede in #1628 (comment)

The SummationByPartsOperators.jl solvers specialize RefElemData, MeshData, and estimate_h from StartUpDG.jl, but do so in a way which is technically type piracy. See for example

Trixi.jl/src/solvers/dgmulti/sbp.jl

Lines 62 to 64 in 92dedde

	function StartUpDG.RefElemData(element_type::Line,
	D::AbstractDerivativeOperator;
	tol = 100 * eps())

This type piracy can be addressed by moving these specializations into to StartUpDG.jl

[ranocha]

They could basically be defined in a package extension for StartUpDg.jl, I think?

[sloede]

They could basically be defined in a package extension for StartUpDg.jl, I think?

Yes, that should work, but OTOH why the additional hassle? They do not depend on Trixi.jl types afaict, so they could just as well live in StartUpDG proper.

[ranocha]

But then StartUpDg.jl would need to depend on SummationByPartsOperators.jl without any real reason. Thus, we should either keep it like it is right now with type piracy where it is needed (in Trixi.jl) or make it a package extension.

[sloede]

Ah, my bad, I thought it already was a dependency there. You're right, a Pkg extension seems the cleanest solution here.

[jlchan]

Closed by #1665