[CI] Darwin test job fails with macos-14

[straight-shoota]

We get a CI failure when updating the GitHub Actions runner image for the darwin test job to the latest release, macos-14 (#14833).
This is the first runner image on aarch64 (M1). The previous ones, including macos-13 use x86_64 processors.

The CI job fails mysteriously without any clear error message:

2024-07-26T09:07:28.8421830Z make: *** [Makefile:106: std_spec] Trace/BPT trap: 5
2024-07-26T09:07:28.8480030Z on_nix_shell_eval nix-shell --pure --run 'TZ=America/New_York make crystal primitives_spec std_spec compiler_spec docs verbose=1 order=default threads=1 junit_output=.junit/spec.xml DOCS_OPTIONS="--json-config-url=/api/versions.json --canonical-base-url=https://crystal-lang.org/api/latest/"' exited with 2
2024-07-26T09:07:28.8510890Z ##[error]Process completed with exit code 1.

I've tried rerunning multiple times and the last executed spec is always in spec/std/tuple_spec.cr, after Tuple does to_a, so this might be a clue. The next spec would be Tuple #to_static_array. There's no indication that this spec even starts running, but this might be an output glitch (i.e. stdout isn't flushed for some reason after printing the spec name).

It's worth noting that this only happens when std_spec is built with a fresh compiler (make crystal std_spec), not with the first run using the previous compiler (make std_spec). The latter one completes successfully.
So this might well be caused by a compiler bug that we haven't noticed before.

When building std_spec, the linker prints a ton of warnings like this (apparently for every object file generated by the compiler):

2024-07-26T09:06:36.6700960Z ld: warning: object file (_main.o0.o) was built for newer macOS version (14.0) than being linked (11.0)

This could be related to the issue, but might as well not be relevant at all.

[HertzDevil]

Reproducible on my M2 when using LLVM 12 or below:

ary = {1, 'a', true}.to_static_array
p ary

StaticArray[0, 'a', Program hit a breakpoint and no debugger was attached

This seems to be exactly #11358, so the same workaround applies here.

[straight-shoota]

Yeah looks like updating LLVM in shell.nix should solve this then.

Related: #14651