Fix(CspParser): accept reserved words as property/method names and object keys

[MaxencePaulin]

Summary

• Reserved words like delete, new, true, null, undefined, etc. couldn't be used as property or method names after a . or as object literal keys in the CSP build, even though this is valid JavaScript. This broke Livewire's wire:click="delete" directive, which compiles down to x-on:click="$wire.delete()".

• Real ECMAScript distinguishes Identifier (variable references, reserved words forbidden) from IdentifierName (property names, reserved words allowed). The CSP tokenizer already classifies its own reserved words (KEYWORD, BOOLEAN, NULL, UNDEFINED) into their own token types, and they should all be usable as property names just like ECMAScript's IdentifierName allows for its own reserved words. Member access (.foo) and object literal keys only accepted IDENTIFIER, rejecting the rest.

• Added checkIdentifierName()/consumeIdentifierName() to the parser to accept any identifier-name-eligible token and resolve it to its string form. The tokenizer stays context-free, the fix lives entirely in the parser.

• Variable references (parsePrimary) are untouched: reserved words still can't be used as bare identifiers, matching real JS.

Note

While auditing this, I also noticed object literals don't accept a NUMBER key ({ 5: 1 }, valid in real JS via LiteralPropertyName). I haven't hit this in a real-world case, not sure it's worth a separate issue, but it might come up eventually i suppose.

Test Plan

• Added tests for reserved-word property access, method calls, and object literal keys (keyword/boolean/null/undefined)
• Added a test for the parse error when . isn't followed by a valid identifier name
• Full csp-parser.spec.js

Fixes #4904