Provide DIC-friendly, concurrency-safe alternative(s) to `drupal_static()`

Some notes from reading related issues: There's ResetInterface from Symfony, which exists to help reset objects to their original state.

In addition, some Drupal modules such as Commerce use SplObjectStorage to map a request to a resolved value. There's still the question of how long this should stay in memory, but it's prior art worth noting.

It seems the "correct" thing to do is require services be stateless, however that's a pretty big change in paradigm for Drupal overall and would in theory require us some way of validating and enforcing this requirement. It's also a likely security hotspot.

@bradjones1 Yes, very relevant questions.

So we have existing code that relies on carrying request-specific state, in a world where that assumption does not hold anymore.
Whar are our minimally invasive solutions?

Build a fresh container, and give each request a deep copy of it, to throw away in the end. Saves us at least container-building, but the deep copy is the expensive part.

Then add a blessed stateless_service tag, and only swap out the remaining services for a new request.

Something like $kernel->rebuildContainerForNewRequest(), as minimal API for now. And maybe in the end we can live with throwing away a handful of services.

If we do use Symfony\Contracts\Service\ResetInterface we could collect all services implementing that interface at container build, and provide a simple way to call reset() on them all when needed.