Use @concrete for Tsit5Cache to hide non-dispatch type parameters

[lo2545]

Summary

Refactors Tsit5Cache to use @concrete from ConcreteStructs.jl
instead of the manually parameterized @cache struct.

Motivation

When users work with custom unit types (e.g., Unitful.jl), error
stack traces become unreadable due to type parameter pollution:

Before:
Tsit5Cache{Vector{Quantity{Float64, 𝐋 𝐓⁻¹}},
Vector{Quantity{Float64, 𝐋 𝐓⁻²}},
Vector{Float64},
typeof(trivial_limiter!),
typeof(trivial_limiter!),
Serial}

After:
Tsit5Cache

Changes

• Added ConcreteStructs.jl as a dependency in Project.toml
• Replaced @cache struct Tsit5Cache{uType, rateType, ...} with
  @concrete struct Tsit5Cache
• All internal types remain fully concrete — no performance regression

Testing

All existing tests pass.

[ChrisRackauckas]

This isn't the same. The @cache struct is used to populate the cache iterators for resize! definitions, and this new definition has many more type parameters than what's necessary (longer stack traceS).

[lo2545]

I've updated the approach. Instead of modifying the struct parameters
(which broke allocations and @cache), I added Base.show overrides that
display only the relevant uType to the user. All tests pass including
the allocation-free check.

[ChrisRackauckas]

This will have major invalidations so it's not recommended.

[lo2545]

Thank you for the feedback! Sorry. I understand that Base.show overrides
cause invalidations.

Could you give a hint on the correct approach for hiding non-dispatch
type parameters without breaking @cache and allocation-free performance?

Should I use a wrapper type like struct Opaque{T} val::T end,
or is there a pattern already used elsewhere in SciML for this?

[oscardssmith]

I don't think this will invalidate badly. The invalidation issue is show on types. changing showing of the type of a value is fine.

[ChrisRackauckas]

If it's just the value, that doesn't do much though? The stacktrace and everything is untouched?

[oscardssmith]

stack traces are untouched, but this will clean up things like test failures that print the values.

[oscardssmith]

to be clear, I'm not saying this is necessarily a good idea, just that it's not an invalidation issue.

[lo2545]

Would overriding Base.show on the type itself fix the stack traces?
Base.show(io::IO, ::Type{<:Tsit5Cache}) = print(io, "Tsit5Cache")

Is this the right approach?

[oscardssmith]

no. that's the thing that causes endless invalidations.

[lo2545]

What is the recommended approach then?