Msvc ops changes

[JacobSzwejbka]

Summary

MSVC really doesn't like the constexpr variables that I've removed in this PR. It was complaining about them not actually being static at compile time. Searching around suggests that its the act of putting them in a variable that breaks it and if I just place the value directly in all the used locations it should be fine. I tried that and it works.

The other changes are fixing up some compiler flags, adding a missing include, fixing an interaction between lambdas the ternary operator and auto, and removing unneeded statement expressions

Test plan

current ci to verify no regression on linux/mac. Manual testing of msvc will add ci soon

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/15226

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 3 Unrelated Failures

As of commit 9f79431 with merge base b7e5cff ():

NEW FAILURES - The following jobs have failed:

• pull / unittest / macos / macos-job (gh)
  export/tests/test_target_recipes.py::TestTargetRecipes::test_mv3_model
• pull / unittest-nxp-neutron / linux-job (gh)
  RuntimeError: Command docker exec -t 7635fb9bd1230a33d2cc41b44b5a4783de9d6d05ff878546b9c52881f2a2f236 /exec failed with exit code 1

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• pull / unittest-arm-backend-with-no-fvp (test_pytest_models) / linux-job (gh) (detected as infra flaky with no log or failing log classifier)

BROKEN TRUNK - The following jobs failed but was present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / linux / linux-job (gh) (trunk failure)
• pull / unittest-editable / linux / linux-job (gh) (trunk failure)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[swolchok]

if this requires more than 1-2 more review rounds, you might be able to move faster by splitting out the uncontroversial strings changes; I could approve those right away.

[JacobSzwejbka]

oh missed one.

[swolchok]

looks good, just a couple minor comments

[JacobSzwejbka]

Test failures do not look related