Introduce TmpCache struct for better temp caching interface

[jClugstor]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Add any other context about the problem here.

[jClugstor]

@oscardssmith would you give me your opinion on this? Just a small demo to show the idea

The idea is basically to consolidate most of the temporary cache space needed in to one struct, particularly it has all of the cache space needed so that initdt doesn't need to allocate. Then we could also expose a toggle so that users could turn the precaching on / off, depending on whether or not they expect to need to reinit and re-determine the dt a lot.

[oscardssmith]

This looks better than nothing, but IMO a slightly more invasive version might be better. Speicifally, it would be kind of nice if we could use the same tmp variables for the init_dt that we use for solve. The way to do this (I think) would be to get rid of most of the caches from the solver specific caches, and move them over to this as well.

OTOH, I guess that is a reasonable followup rather than making it part of this.

[jClugstor]

Well, I might as well see if I can get Claude Fable to whip something up, might as well use it while it's available :) .

But yeah in that case many many files will be touched.

[jClugstor]

use the same tmp variables for the init_dt that we use for solve.

This actually does that already, in tsit5 perform step for example it accesses the TmpCache object in the tsit5 cache, sorry, misunderstood what you meant.

But yeah that's basically the idea, consolidate the most used scratch spaces and then use that in both init dt and the solve.

So things like tmp, utilde, atmp, would now be held in TmpCache. But probably things like the stage vectors, nlsolve stuff, jacobian stuff can stay as fields in the solver caches?

[ChrisRackauckas]

Lots of methods are sensitive to the exact number of u-sized vectors allocated. Wherever possible, this should not introduce new allocations but should alias existing ones in order to keep the total cache size capped. The LowStorage methods in particular will directly test this.