Improved symbol handling

[threeseed]

Based on benchmarks the following performance improvements:

LinearClassifier / 100,000 - 94.7%
LinearClassifier / 1,000,000 - 13.7%

LinearRegressor / 100,000 - 48.3%
LinearRegressor / 1,000,000 - 7.07%

[kali]

If I get this right, you "just" replaced the locking structure, right ? The previous iteration was adding an extra cache, but this PR does not, correct ?

[threeseed]

If I get this right, you "just" replaced the locking structure, right ? The previous iteration was adding an extra cache, but this PR does not, correct ?

Yes. We did have a PR for symbol cache which we are still looking into.

But this is about locking and the string interning micro optimisation.

[kali]

Pleasse make sure clippy is happy, and we'll merge this.

[kali]

I think we still have a problem though, some expression will trigger a dead lock (which put the CI in trouble, but that's on me, i need to make it more resilient i guess).

In tract/data, cargo test dim::assertion::tests::low_bound_1 shows the deadlock (a couple other tests in data also do).

[kali]

Thanks for this PR and the accompanying benchmark — the bench itself was invaluable and is what made the underlying contention tractable to track down. I'm going to close
this in favour of a narrower fix, but wanted to share what we landed and why.

Root cause. On the LinearClassifier bench at high thread counts, every set_input was hitting two locked paths in SymbolScope:

1. TDim::to_i64() was being used inside plan.rs::resolve as a "is this concrete?" probe. On a symbolic TDim it constructed an error containing self.to_string(), which
   formats through Symbol::Display and takes the scope lock. (This was regressed by 106161a in January; swapping to the already-existing as_i64() -> Option avoids any
   allocation and any lock.)
2. guess_scenario() acquired the scope lock just to observe that scenarios is empty — the common case.

Numbers (100K parallel runs, 32 threads, Ryzen 9 9950X3D):

  ┌───────────────────────────────┬─────┐
  │                               │ ms  │
  ├───────────────────────────────┼─────┤
  │ main today                    │ 197 │
  ├───────────────────────────────┼─────┤
  │ this PR if it didn't deadlock │ 36  │
  ├───────────────────────────────┼─────┤
  │ with the two fixes above      │ 26  │
  └───────────────────────────────┴─────┘

The lock-free fast path actually edges out the RwLock approach — no lock beats a concurrent-reader lock when the contended work is trivial.

Why not this PR directly.

• The ReentrantMutex<RefCell<_>> → parking_lot::RwLock swap deadlocks on any path that re-enters the scope lock while a guard is held (dim::assertion::tests::low_bound_1 is
  the reproducer). RwLock isn't reentrant, and several hot paths — TDim arithmetic calling simplify(), Symbol::Display, the proof-cache path — re-enter transitively. That's
  fundamental to the approach rather than a localised bug.
• For the rest of the PR I benched each change individually against the bench suite included here. DefaultStringInterner → StringInterner is a no-op (both
  resolve to the same type in string-interner 0.19 and 0.15). FxHashMap on SymbolValues, the positives_cache, Arc<[Assertion]>, and the String::with_capacity buffer reuse all
  stayed within ±1–3 ms on every thread count. They may well pay off in other workloads, but I didn't want to carry them in without a workload where they pull their weight.

Replacement is three commits on #2151 :

• plan: use as_i64 probe instead of to_i64 in shape resolve
• deps: workspace-ize parking_lot
• sym: lock-free fast path for guess_scenario on empty scope

Thanks again — the problem this PR exposed was real and worth fixing.