feat: parse parameter decorators for transforms

[jtenner]

Summary

This PR makes parameter decorators parseable and preservable in the AST so transforms can inspect or remove them before compilation-time validation runs.

This is intentionally not a new end-user language feature. Any parameter decorators that survive transform time still produce TS1206: Decorators are not valid here.

What Changed

• added AST storage for parameter decorators on ParameterNode
• added AST storage for explicit-this parameter decorators on FunctionTypeNode
• taught the shared parameter parser to preserve decorators across function declarations, methods, constructors, function types, function expressions, and parenthesized arrow functions
• updated the AST serializer to round-trip preserved parameter decorators
• added a Program validation pass that rejects surviving parameter decorators once per decorated parameter using the full decorator-list range
• ran that validation after afterInitialize, so transforms can remove the decorators first
• added parser, compiler, and transform coverage for accepted syntax, delayed rejection, and transform-time removal
• documented the transform hook timing in the transform-facing API comments and example transforms

Why

The parser and transform pipeline can use preserved parameter decorators as an AST-level extension point without committing AssemblyScript to supporting them as regular language syntax.

That gives transform authors a useful hook while keeping the language semantics unchanged:

• transforms can read or erase parameter decorators
• the compiler still rejects them if they remain after transform time
• public-facing docs do not need to advertise parameter decorators as supported syntax

Impact

• transform authors can now observe and rewrite parameter decorators before validation
• end users still get TS1206 if parameter decorators survive to compilation
• constructor parameter properties continue to receive no special decorator semantics

Validation

• npm run build
• npm run test:parser -- parameter-decorators
• npm run test:compiler -- parameter-decorators --noDiff
• npm run test:transform

[jtenner]

Whoops! I forgot to check the validation scripts locally. Everything looks good now.

I hope this contribution finds it's way to main because I want to use it to make some very cheeky transforms for my webgpu implementation.

[jtenner]

Is this all set? I rebased it on main and had to add the eslint "ignore" file because of the decorator proof. I left a comment to explain why. Please let me know if anything isn't up to standard!

[MaxGraey]

Why serializeParameterDecorator instead visitParameterDecorator?

[jtenner]

I missed this. Sorry.

[MaxGraey]

You also need to add sample test cases and handle errors properly. Someting like:

function regularEmpty(@first): void {}
function firstEmpty(@first, value: i32): void {}
function regularWrongPos(value @first: i32): void {}
function regularWrongPos2(value: i32 @first): void {}
function restWrongPos(...values @rest: i32[]): void {}
function selfWrongPos(this: i32 @self): void {}

function noLits(@123 value: i32): void {}
function noExprs(@(a + b) value: i32): void {}

[jtenner]

I added another test file. Should be good to go.

[PaperPrototype]

👀 are you planning on using this for WGSL/GLSL translation?