Preprocessor: reject invalid extended identifier as macro name

[chiliec]

What

Closes #593. #define ™ 42 (macro name U+2122 TRADE MARK SIGN) was silently accepted, even though ™ is not a valid identifier character and the parser correctly rejects it in a declaration (int ™; → error: unexpected character <U+2122>).

Fix

define() already rejects a macro name whose token isn't a macro identifier, but any byte in 0x80..0xFF tokenizes as .extended_identifier, which passes that check without the codepoints ever being validated. Added a check that walks the extended-identifier name and confirms every codepoint is allowed in an identifier for the active language standard (reusing Standard.codepointAllowedInIdentifier, the same predicate the parser uses). On failure it emits the existing macro_name_must_be_identifier diagnostic, matching the message requested in the issue.

This is standard-dependent and now matches the declaration path exactly: valid extended identifiers (e.g. Greek α) are still accepted; ™ is rejected wherever int ™; would be rejected.

$ arocc -std=c23 -fsyntax-only tm.c
tm.c:1:9: error: macro name must be an identifier
#define ™ 42
        ^

Tests

• Added test/cases/macro name must be an identifier.c.
• zig build test → 478 passed; 33 skipped and 9007 passed; 2 skipped.
• zig build test-fmt clean.
• Verified genuine RED→GREEN: reverting the new check makes the added case fail (477 passed; 1 failed), restoring it passes.
• Confirmed valid extended-identifier macro names (#define α 42) still work, and that the #define result now matches the declaration path across -std=c99/c11/c17/c23.

Happy to adjust.