Blazor WebAssembly perf: Optimize parameter writer dictionary lookup

[SteveSandersonMS]

This is part of #22432

The PlainTable/ComplexTable benchmarks show that a very large proportion of the overhead of passing each parameter is due to the time we spend doing a dictionary lookup from the parameter name to the cached parameter writer. Currently it's a case-insensitive dictionary lookup which is expensive because string hashing is expensive at scale (it has to consider every character).

We could improve this by putting a further layer of caching in front of the dictionary lookups so that, based on the object identity of the string key (not its string hash), we can immediately find out whether it's a known parameter and if so what the cached writer is. To avoid consuming too much memory in worst-case scenarios (e.g., the developer continually constructs new parameter name string instances), we would limit the cache size arbitrarily (e.g., to 50 items) after which we fall back on the slower existing code path of reading directly from the underlying string-hashing dictionary. This slower path would never be triggered in typical cases, as the string keys are compile-time interned values, and usually there are only a small number of parameter names used by a given component.

Prototype implementation is at e0a4f72. This gives nearly 10% gain for the ComplexTable benchmark.