Bump expected LLVM version to 24

[kripken]

Emsdk tot started to warn on this:

em++: error: LLVM version for clang executable "/home/runner/work/_temp/76654901-710b-43ee-adb0-e0f178e1557c/emsdk-main/upstream/bin/clang" appears incorrect (seeing "24.0", expected "23") [-Wversion-check] [-Werror]

[kripken]

@sbc100 how do we get around the version mismatch? tot has the new version but this repo now rolls a day late. I guess we need to wait for that roll..?

[kripken]

(will the roll actually pass?)

[sbc100]

Hmm.. we have logic that allows this to pass the emscripten-releases CI, but i looks like we need to update the scheme now that we roll emsdk on our end:

emscripten/tools/shared.py

Lines 240 to 245 in ee5cacb

	# When running in CI environment we also silently allow the next major
	# version of LLVM here so that new versions of LLVM can be rolled in
	# without disruption.
	if 'BUILDBOT_BUILDNUMBER' in os.environ:
	if actual.startswith('%d.' % (EXPECTED_LLVM_VERSION + 1)):
	return True

I suppose for this initial change you could include and emsdk update as part of this change? i.e. combine the emsdk update with the llvm update? I guess that actually makes the most sense here because they are intrinsically linked.

[sbc100]

One option here would be to manually trigger an emsdk update here: https://github.com/emscripten-core/emscripten/actions/workflows/update-emsdk.yml

Then when the CI fails, push the LLVM bump into that PR?

We could make the emsdk update script clever enough to do this on its own, but since its only once ever 6 months maybe its not worth it?

[sbc100]

Actually because essentially the same logic need to apply to llvm and binaryen here I think we can/should build it into the --update-emsdk process.. looking into that now.

[sbc100]

I created #27352. Once that lands we can trigger the action it should update the versions for us.

[sbc100]

OK to close this in favor of the auto-generated PR: #27353