fix(ast): serialize Function.params like estree

[hi-ogawa]

• part of Improve AST with respect to estree #2854

This PR attempts to handle estree ast incompatibility of Function.params: FormalParameters as mentioned in the above issue:

FormalParameters is closer to ESTree now, but should be inlined directly into <node>.params in multiple nodes.

Estree spec has Function.params: Pattern[] https://github.com/estree/estree/blob/master/es5.md#functions, but oxc already has interface Pattern, so I named it to Function.params: ParamPattern[] for now.

Also I'm not sure about the testing (I suppose that's a part of #8630), so I snapshoted one example code. For comparison, here is acorn's output https://astexplorer.net/#/gist/25138c0605f82dcfc1a8fd363dc2a681/5ad30d36c9f276519063e6fd2e340c113d8c85b0

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[codspeed-hq]

CodSpeed Performance Report

Merging #8772 will not alter performance

_{Comparing hi-ogawa:fix-estree-no-FormalParameters (9f2240e) with main (e930cae)}

Summary

✅ 33 untouched benchmarks

[overlookmotel]

Looks good!

However, I'd like to wait for #8897 to land before merging this, as that PR changes how you define custom TS types - it removes the custom_types.d.ts file in favour of defining TS type defs in attributes on the Rust type definitions.

I'd prefer not to restack that whole lot of PRs on top of this as CI on large stacks takes quite a long time, but I'll fix this one once #8897 lands, and will get it merged then.