[release/8.0] Fix stack_limit handling (#91095)

[release/8.0] Fix stack_limit handling (#91095)

* Fix stack_limit handling

There is a problem with computing stack_limit in the presence of
inactive InlinedCallFrame. We were trying to call GetCallSiteSP on that
frame to get the call site SP. But when the inlined call frame is not
active (there is no call to native code in progress), that method
returns random junk.

But even if we checked for an active call before reading the value, it
would not get correct stack limit on x86 windows when there was no
active call with the inlined call frame being the topmost one. That
can happen with hardware exception handling on Windows x86. On other
targets, we always have other explicit frame on top of the explicit
frames stack, but on windows x86, we don't use the FaultingExceptionFrame for
hardware exceptions, so the inactive inlined call frame could be the
topmost one when GC starts to scan stack roots.

Since the stack_limit was introduced to fix a Unix specific problem, I
have fixed that by disabling the stack_limit usage for x86 windows.

Close #86265

* Add back the stack_limit field to keep contract unchanged

* Reflect PR feedback - Minimalize the number of ifdefs

* Reflect PR feedback

---------

Co-authored-by: Jan Vorlicek <janvorli@microsoft.com>