Change stack size on all desktop platforms to at least 1.5MB

[hamarb123]

Fixes #87879
Fixes #2084
Fixes #1417

Changes the stack size on desktop platforms to a certain minimum.

Specific changes we've landed on:

• macOS secondary thread stack size is upped to match Windows thread size at 1.5MB (and other Apple platforms, mono was already 2MB for these since they're all 64-bit)
• Windows NAOT is upped to the standard 1.5MB
• Allow IlcDefaultStackSize to be used to specify the stack size for NAOT on all platforms

Plan:

• Change stack size on all 64-bit desktop platforms to 4MB and add tests
• Make sure tests all run
• Make sure tests all pass
• Remove API changes
• Determine if we want to keep it at 4MB, and if not, reduce it, also determine if we want to change 32-bit platforms too
• Re-enable any tests previously disabled due to stack size

(Already reverted) Note: I've currently made some changes to System.Reflection.Metadata's API, I don't plan to keep these - I had noticed that NAOT seemed to only be giving 1MB on Windows though when I built it a test console app, so I am seeing if it fixes that before doing a more proper fix.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[hamarb123]

(force push & empty commit were to workaround #98009)
(edit: it didn't work lol)

[jkotas]

As I have mentioned in #87879 (comment), I think that we should only fix macOS. Bumping the stack size on Windows is likely to introduce as many problems as it fixes.

[hamarb123]

@janvorli what are your thoughts on the stack sizes we should change? I currently have them all at 4MB for 64-bit desktop platforms, but this is mainly for testing (not that I would complain if we ended up on this number 😆). Would you be happy with 2MB for all desktop platforms?

As I have mentioned in #87879 (comment), I think that we should only fix macOS. Bumping the stack size on Windows is likely to introduce as many problems as it fixes.

@jkotas would you accept 2MB also? It is only marginally higher than the current Windows value (1.5MB). I think it is a good middle ground, and should be enough to account for the ever-expanding usage of the stack that I mentioned in #87879 (comment) for the time being (and we could obviously re-visit it in the future if we wanted to increase it again).

[hamarb123]

I've found these 3 disabled tests due to macOS stack size, are there any others which I should re-enable with this fixed?

[jkotas]

@jkotas would you accept 2MB also? It is only marginally higher than the current Windows value (1.5MB

I don't see a good reason for changing the Windows stacksize. We would need to file a breaking change notice for it and it would be hard to come up with a good justification.

[jkotas]

LGTM otherwise. Thank you!

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[hamarb123]

Should runtime-extra-platforms be run also @jkotas? (I can't run it, but I would think it makes sense, right?)

[jkotas]

I just wanted to double check that the new test is running as part of runtime-nativeaot-outerloop (confirmed - it does).

[jkotas]

Thank you!