Data race in CUtlSymbolTableMT lookup.

[RoyaleNoir]

CUtlSymbolTableMT::Find uses a read lock, where it should be using a write lock, as the function it is wrapping writes to a member variable of CUtlSymbolTable. This causes a race condition if two different threads attempt to look up a symbol in the same table.

[dimhotepus]

THIS IS COMMON BUG IN AT LEAST HL2 / HL2 Episodes / Portal / TF2 GAMES.

For example it causes HL2 coast or TF2 maps with water begin to blink due to Water shader can't find fog variables in
CUtlSymbolTable.

The problem is CUtlSymbolTableMT::Find may be called by multiple threads at once. It creates
read lock and calls CUtlSymbolTable::Find. CUtlSymbolTable::Find in turn stores
searched string inside class to access it in the tree lookup. It means when CUtlSymbolTableMT::Find
called by multiple threads, its search string may be changed in the middle time during lookup as
read lock doesn't protect against writes.

At least one known bug: ValveSoftware/Source-1-Games#4937

There are different possible ways to fix the one:

1. Mark user search string as CThreadLocal: Source-Authors/Obsoletium@663a12a. Downside is it adds TLS access overhead in regular CUtlSymbolTable.
2. Extend Find context for CUtlRBTree aka add context to comparator: Source-Authors/Obsoletium@b995016. It is a bit ugly (guess can be done better), but no performance overhead for TLS access as we just use search string from stack-local context (no thread safety issues).

[ficool2]

I fixed this months ago in my mod but I've opened a PR for it now #1807