Consider the case of a partially interruptible function where we've replaced
each call site with INTERRUPT_INSTR_CALL or INTERRUPT_INSTR_CALL_32. Even
though the call site itself isn't a safe point, we put a GCStress instruction
there so we can capture the call target at GC stress time, then set a specific
GCStress instruction for the next instruction that will indicate how to GC
protect any GC refs that are returned from the call.

Multiple threads can enter `DoGcStress` at the same time. They all get just
past the race check `if (!IsGcCoverageInterruptInstruction(instrPtr)) return;`.
One goes ahead, and reads the instruction code for the address at which we're
doing a GCStress. We set `atCall` to `true` if this matches one of our known
GCStress instructions for partially-interruptible call sites. Later, if
`atCall` is `true`, we write the original call instruction back to the code
stream, write the distinguished next instruction GCStress instruction, and
continue. If the other threads then read at the instruction address, they
might read the actual call opcode, not the distinguished GCStress breakpoint
instruction code. Then, they will set `atCall` to `false`. This will indicate
that we are in a fully-interruptible location, or that no special call-site
behavior is required. We go on, force a GC, and eventually get to the assert
in `EECodeManager::EnumGcRefs` that we are at a GC safe point.

The solution is to simply move the `if (!IsGcCoverageInterruptInstruction(instrPtr))`
check below the read of `*instrPtr` to set `atCall`.

Re-enable the GitHub_27924 test.

Fixes dotnet#36681