ci: adopt shared tccbin conformance test suite

[quaesitor-scientiam]

Wires this branch into the shared cross-platform conformance suite
(thirdparty/tccbin_tests in vlang/v) already running on
thirdparty-windows-amd64's CI and proposed for thirdparty-linux-amd64
(#69) — same shared/hello.c, gc_alloc.c, crash.c tests.

TCC on macOS arm64 cannot yet link the Clang-built static libgc.a
(documented in this branch's README.md), so rather than skipping the
GC-dependent shared tests here, this mirrors the dynamic
libgc.dylib + rpath approach V's own builder already uses on this
exact platform (vlib/builtin/builtin_d_gcboehm.c.v):

#flag @VEXEROOT/thirdparty/tcc/lib/libgc.dylib
#flag -Wl,-rpath,"@VEXEROOT/thirdparty/tcc/lib"

• hello.c and gc_alloc.c (both GC-dependent) run against
  libgc.dylib as the blocking lane.
• crash.c (no GC) runs unconditionally.
• A second lane against the static libgc.a is kept as a temporary,
  explicit XFAIL (continue-on-error: true) rather than silently
  dropped — it runs for visibility (so a regression that makes it fail
  differently is still noticed) but never blocks CI. Remove
  continue-on-error and fold it back into a single blocking lane
  once static linking is supported.

Also rebuilds tcc.exe from source via this branch's own documented
build.sh recipe (reusing the already-committed libgc.a/libgc.dylib,
not rebuilding those) as a build-reproducibility check, uploading the
result as an artifact.

One non-obvious thing worth calling out for reviewers, the same gotcha
found on the Linux side (#69): the bundled tcc.exe
resolves its own runtime library path relative to the process's
working directory at invocation time, not via -B or argv0 - matching
how V's own builder os.chdir()s to the V root before invoking
bundled tcc. Every tcc invocation in this workflow runs with
working-directory: work and refers to the compiler as the relative
path thirdparty/tcc/tcc.exe for that reason.

Verified with a real macos-latest (Apple Silicon) Actions run on the
fork: all steps green, including the blocking dynamic-libgc.dylib
lane; the static-libgc.a XFAIL lane fails as expected and is
absorbed by continue-on-error without failing the job.
https://github.com/quaesitor-scientiam/tccbin/actions/runs/30053212222

TODO: thirdparty/tccbin_tests isn't in vlang/v yet (open PR
vlang/v#27924), so this points at the fork branch it's proposed on.
Once/if that merges, this should switch to repository: vlang/v at a
real commit.