Fix CRWLock ID generation overflow bug

Fix CRWLock ID generation overflow bug

There are several problems with the CRWLock constructor, where it tries to increment a 64-bit lock ID in two 32-bit pieces using lock-free code in a fast path:
- For the lower 32 bits, LLockID, zero is reserved for identifying a free lock entry. Upon incrementing LLockID from -1 to 0, the code was not skipping zero or incrementing the upper 32 bits, ULockID. Instead, it waited for one more increment to LLockID before increment ULockID. Assignment of the invalid LLockID caused a free lock entry to be reused for a new lock, and corruption in lock state thereafter. This is the issue identified by the bug.
- If LLockID != -1 in thread A, but the compare-exchange fails because thread B had updated the value before thread A, ULockID was not being read again in thread A. If thread B had also incremented ULockID, thread A would continue to use the old ULockID.
- In the locked slow path that handles incrementing ULockID, ULockID is updated before LLockID. The constructor though, was reading ULockID before LLockID. This allows a race where Thread A reads an old value for ULockID and a new value for LLockID, increments LLockID successfully, and continues to use the old ULockID.

Due to the availability of InterlockedCompareExchange64 on all supported platforms, we decided to use that instead to simplify the solution and fix all of the above issues at the same time.

Bug: 242568
Integrated from changes: 1621197, 1621810

[tfs-changeset: 1622814]

Commit migrated from https://github.com/dotnet/coreclr/commit/6ad3d45d6b9096b64c9d9ea933efe5f49f08c81f