Improve the smallIntegerValueCache added during InclusiveRange implementation

[darkdrag00nv2]

Issue to be solved

The cache is thread safe and we should measure if there is an advantage in having the cache vs the downside of having a lock.

Comment from @turbolent on #2523

Given that the cache is global, different interpreter runs, in tests or not, might concurrently hit the cache, so it needs to be safe. So far all other "state" is interpreter-instance specific and not global.

My gut feeling is that the overhead of making this thread-safe and lock contention might be worse than the benefits of caching/re-using existing values. We might want to check and optimize this if needed, Maybe best to do that in a follow-up PR, this one is already quite large.

Suggested Solution

No response

[darkdrag00nv2]

Based on the benchmark results from #2936, we are okay with using the cache.