AsyncSemaphore fix for deadlock in narrow cancellation race condition

[AArnott]

This avoids calling CancellationTokenRegistration.Dispose while holding a private lock in EnterAsync. There is one remaining case where we may hold a lock while calling it, but that's in the inlined case of EnterAsync and CTR will have its default value, and thus could not have anything to block on.

The problematic case that we're fixing is when the token is canceled while EnterAsync is executing between where the CTR is assigned and where we called info.Cleanup(). In such a case, we would deadlock because Cleanup would wait for handlers to complete but the handler is waiting for the lock.

There is no unit test change as part of this because the race condition is so very narrow that we couldn't write a unit test that would reliably hit it. However, I did temporarily make a code change that would throw when we held a lock in the evil case and our stress test did hit it before the fix and did not hit it after the fix, so I feel with that manual testing that we likely resolved the issue.

Fixes #1000

[jasonmalinowski]

Seems reasonable to me, given this is the standard "dispose outside of the lock" pattern. I won't pretend to understand the precise data structures involved here but nothing looks amiss.

[lifengl]

the change looks good to me.