Investigate: Special case Lock type in the lock function

As pointed out in https://github.com/dotnet/runtime/pull/103085#issuecomment-2150981294, lock shouldn't use new Lock type in the Monitor, as it might misbehave.

We can't use fslib special syntax for it to have separate implementation, since the type is not in the netstandard.

Two other ways for having its implementation separated for Lock and other types are

1. Make it a compiler intrinsic, which is probably a "no" for us.
2. Check the type in runtime, which might impact performance, since we'll have to use reflection for it, as well as might be a breaking change for some of the customers.