…ed layouts (#107075)

* Ensure the layout of `StackAllocatedBox<T>` matches boxed layouts

The boxed layout of a struct always has its data at +8, as evidenced by
`Object::UnBox`. This means that `StackAllocatedBox<T>` should have
`Pack = 1`, otherwise this may not be the case. In the test failure we
had a `StackAllocatedBox<Int128>` which had its `_value` field at offset
16. After object stack allocation this meant that we were saving data in
padding of the structure, which promotion does not guarantee to
preserve.

Fix #106947

* Run jit-format

* Correct enum

---------

Co-authored-by: Jakob Botsch Nielsen <jakob.botsch.nielsen@gmail.com>
Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>

Co-authored-by: Tanner Gooding <tagoo@outlook.com>
Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>

There was one more case where we have saved the stack trace into the _remoteStackTraceString
field in the exception when the exception was passing from reflection invoked code
to the caller of that code. While there is no visible difference in the Exception.ToString,
a SOS test was failing due to that. And it is not necessary to save the stack trace
there.

I have thought about the cases when we really need the stack trace saved into the
_remoteStackTraceString and I believe that actually the only case is when an existing
exception is thrown again in managed code. So I have removed the option to save the stack
trace from all the variants of the DispatchManagedException.

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

…uous) (#107097)

* slicing fixes

* rebased on main

---------

Co-authored-by: Michael Sharp <misharp@microsoft.com>

* Change BuildWithFactoryReadDirect to not use RSA+MD5

* Add Azure 3.0 helix test

---------

Co-authored-by: Kevin Jones <kevin@vcsjones.com>
Co-authored-by: Rich Lander <rlander@microsoft.com>

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>