parser: cannot tokenize __extension__ ((vec)(scalar){...}) compound-literal vector casts (mmintrin.h / windows.h)

## Summary

ncc's tokenizer/parser fails on `__extension__ ((vec_type)(scalar_type){…})` compound-literal vector casts as emitted by gcc/clang's MMX/SSE intrinsic headers (`mmintrin.h`, etc.). Any translation unit that includes — directly or transitively — a header that uses this pattern fails ncc's parse phase before it reaches clang.

## Repro

When using ncc as the project compiler with `--target=x86_64-w64-windows-gnu` (llvm-mingw 20260421 / clang 22.1.4), compile any TU that pulls in `` or ``:

```c
#include // pulls in mmintrin.h transitively
```

Result:

```
ncc: parse FAILED (80227 tokens produced)
last 10 tokens:
[80217] tid=123 "{"
[80218] tid=1073741959 "return"
[80219] tid=1073741881 "__extension__"
[80220] tid=40 "("
[80221] tid=1073741825 "__m64"
[80222] tid=41 ")"
[80223] tid=40 "("
[80224] tid=1073741825 "__v2si"
[80225] tid=41 ")"
[80226] tid=123 "{"
```

The construct ncc is choking on is the GCC-vector intrinsic pattern, e.g.:

```c
__attribute__((__always_inline__, __nodebug__))
static __inline__ __m64 _mm_setzero_si64 (void)
{
return __extension__ (__m64) (__v2si){0, 0};
}
```

## Affected real-world TUs (n00b)

- `subprojects/mir/mir.c` and `mir-gen.c` (transitively via `` on `--target=x86_64-w64-windows-gnu`). Workaround in n00b's `subprojects/mir/meson.build`: `custom_target` driving `$LLVM_MINGW/bin/x86_64-w64-mingw32-clang` directly instead of routing through ncc.
- `src/util/path.c` once it `#include ` for `GetModuleFileNameA`. Workaround on `n00b-lang/n00b@foundation` (commit `6bbd08c`): forward-declare `GetModuleFileNameA` instead of including ``.

Both workarounds are ugly — neither generalizes for callers that need broader Windows API surface.

## Suggested fix

Teach ncc's parser the `__extension__` keyword followed by a parenthesized cast / compound-literal expression. The relevant grammar fragment (per gcc-extensions docs) is roughly:

```
unary-expression: __extension__ unary-expression
postfix-expression: ( type-name ) { initializer-list }
```

Either:

a. Recognize `__extension__` as a leading "ignore-and-parse-as-normal" prefix, and add support for compound-literal expressions of vector types in the existing parser.
b. As a quick mitigation, make ncc fall through to the underlying clang for any TU whose preprocessor output contains `__extension__\s*\(\s*\(\s*__m\d+|__v\d+`, bypassing ncc's parser. Not ideal long-term but unblocks Windows / SIMD-heavy code immediately.

## Why this matters

This is the hardest blocker for using ncc as the C frontend in any Windows-targeting build that touches ``, and for several intrinsics-heavy host libs (MIR being the most prominent one in the n00b ecosystem). Each consumer is currently writing its own workaround.