red-knot: introduce a StatisticsRecorder trait for the KeyValueCache

[AlexWaygood]

Summary

This PR changes the DebugStatistics and ReleaseStatistics structs so that they implement a common StatisticsRecorder trait, and makes the KeyValueCache struct generic over a type parameter bound to that trait. The advantage of this approach is that it's much harder for the DebugStatistics and ReleaseStatistics structs to accidentally grow out of sync in the methods that they implement, which was the cause of the release-build failure recently fixed in #11177.

Test Plan

cargo test -p red_knot and cargo build --release both continue to pass for me locally

[MichaReiser]

I like the trait, but making KeyValueCache generic over S feels heavyweight because it increases the complexity of using the type (yes, it defaults to a type, but you still get scared away by three generics when looking at the type).

[AlexWaygood]

Makes sense. Is there a way of using a trait here without making KeyValueCache generic? If not, I'm not wedded to this approach -- happy to do something else with this, or not do anything at all!

[AlexWaygood]

I suppose I could do statistics: Box<dyn StatisticsRecorder>?

[MichaReiser]

You could, but that requires an allocation and adds an overhead to cache lookups (even when it's the release statistics).

I think we should not over-engineer this. We might even go with always having statistics. This is just some prototype code.

[AlexWaygood]

Makes sense. Should I just close this for now, then? :-)

[MichaReiser]

I like the trait. I would just remove the type param.

[AlexWaygood]

Ohh, I think I see what you mean. Sorry for being dense.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[carljm]

Going to let @MichaReiser confirm if this looks ok.