Apply the same optimization as #19978 to comments - hold a pool of `Comment` objects, and re-use those objects rather than creating new objects each time.

Same as with `Token`s, `loc` property is a getter which calculates `loc` lazily, and caches it in a private property.

### 🐛 Bug Fixes

- edb8677 ecmascript: Treat collection constructor with variable arg as side-effectful (#20383) (Dunqing)
- 1f65c3f transformer: Emit design:paramtypes when class has static anonymous class expression (#20382) (bab)
- fa70d5c transformer: Use implementation signature for design:paramtypes when constructor is overloaded (#20394) (bab)
- ed5a7fb parser: Report syntax error for `new super()` (#20384) (Boshen)
- e62524d minifier: Treat object spread of getters as having side effects (#20380) (Boshen)
- f8fbd6e linter/plugins: Remove `hashbang` property from AST (#20365) (overlookmotel)

### ⚡ Performance

- 30a2b0f minifier: Use atom_from_strs_array for template literal concat (#20386) (Boshen)
- 690ce17 minifier: Use Vec::with_capacity for inline template expressions (#20389) (Boshen)
- 9cd612f linter/plugins: Recycle comment objects (#20362) (overlookmotel)

Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>

# Oxlint
### 🚀 Features

- c95951f linter/plugins: Implement `sourceCode.markVariableAsUsed` (#20357) (overlookmotel)
- 7a2a7d0 linter: Implement `n/handle-callback-err` rule (#19616) (Mikhail Baev)

### 🐛 Bug Fixes

- f8fbd6e linter/plugins: Remove `hashbang` property from AST (#20365) (overlookmotel)
- 6eb5b01 linter/prefer-await-to-then: Ignore Promise static methods (#20347) (camc314)
- a4b61f7 linter: Remove `defineConfig` check (#20308) (camc314)
- 3ad7f53 linter/explicit-module-boundary-types: False positive with satisfies expr (#20309) (camc314)
- f547401 linter/no-unused-private-class-members: Treat switch discriminants as read (#20307) (camc314)
- 1c07b3b diagnostics: Handle `WouldBlock` in stdout writes to prevent panic (#20295) (Boshen)

### ⚡ Performance

- e4f7248 linter: Remove unnecessary clone of owned String in drain loop (#20388) (Boshen)
- 4a67f1d linter: Eliminate Vec allocation in disable directive matching (#20387) (Boshen)
- 618a598 linter/plugins: Add fast path for files with no comments (#20366) (overlookmotel)
- b0125c5 linter/plugins: Deserialize comments without AST (#20364) (overlookmotel)
- 9cd612f linter/plugins: Recycle comment objects (#20362) (overlookmotel)
- bf442f8 linter/plugins: Cheaper `Token` creation (#20360) (overlookmotel)
- 5474d0a semantic: V8-style walk-up reference resolution (#20292) (Boshen)
- 7946eba linter/plugins: Avoid arguments spread and temp array when merging (#20318) (overlookmotel)
- fc7cf8a linter/plugins: Pre-define less CFG merger functions (#20317) (overlookmotel)
- 3b9eb28 linter/plugins: Streamline getting/creating visit fn mergers (#20319) (overlookmotel)
- f04e850 linter/plugins: Inline binary search functions into call sites (#20312) (overlookmotel)
- fe24afe linter/plugins: Apply replace globals TSDown plugin to JS files (#20305) (overlookmotel)
- 77cdacc linter/plugins: Use array buffer views for tokens (#20301) (overlookmotel)
- 910c941 linter/plugins: Reorder branches in `getTokenByRangeStart` (#20296) (overlookmotel)
- af7674c linter/tokens: Avoid extra token value allocation (#20013) (camc314)

### 📚 Documentation

- 24490b5 linter: Improve formatting for 80ish rules' docs. (#20411) (connorshea)
- 3383523 linter: Improve `--tsconfig` flag docs (#20342) (camc314)
# Oxfmt
### 🚀 Features

- d22c443 oxfmt: Export `OxfmtConfig` type (#20275) (leaysgur)
- a11ecff oxfmt/lsp: Respect `angular` language id as `.component.html` file (#20242) (Sysix)

### 🐛 Bug Fixes

- ce65099 formatter: Preserve parentheses around as expression before private field access (#20419) (bab)
- f908742 oxfmt: Revert #20326 partially (#20413) (leaysgur)
- 4ef93ea formatter: Honor trailing ignore comments after list separators (#19925) (Andreas Lubbe)
- 68fb0d0 oxfmt: Skip vite.config.ts which fails to import (#20326) (leaysgur)
- 88ee826 oxfmt: Handle literalline for script-in-vue (#20130) (leaysgur)
- 1c07b3b diagnostics: Handle `WouldBlock` in stdout writes to prevent panic (#20295) (Boshen)

Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>

Fix a JS-side memory leak from tokens and comments.

## The problem

V8 uses "SlicedString" optimization to avoid copying string data. `sourceText.slice(10, 20)` does not copy bytes 10..20 to a new string, but references the original string data of `sourceText` (much like `&str` in Rust).

#19978 and #20362 introduced caching and recycling of `Token` and `Comment` objects. This was a large performance gain.

However, it contained a flaw. The problem is that `Token` objects now live forever, and they contain little slices of the source text in their `value` property. This means they prevent the source text which they reference from being garbage-collected, and therefore it lives forever too (or at least until another file with an equal or greater number of tokens overwrites the `value` property of all the `Token` objects).

## Solution in this PR

Fix this by setting the `value` property of all `Token`s and `Comment`s to `null` after linting a file in `resetTokens` and `resetComments`.

## Implementation details

This requires some additional book-keeping to track which tokens have been deserialized and which haven't, so that `resetTokens` / `resetComments` do the minimum amount of work necessary - only resetting tokens / comments which actually had their `value` property set in the first place.

The indexes of tokens are stored in 2 x `Uint32Array`s `deserializedTokenIndexes` and `deserializedCommentIndexes`. A simpler solution would have been to store the `Token` / `Comment` objects themselves in a plain `Array`, but `Uint32Array` has 3 advantages:

* 4 bytes to store index (`u32`) per token/comment, instead of 8 bytes to store a pointer to the `Token` / `Comment` itself.
* Faster to write to `Uint32Array` - no write barrier checks.
* On GC runs, a `Uint32Array` is known not to contain references to any other heap objects, so GC tracing doesn't need to walk it, which it would with an `Array`.

`Uint32Array` does have one disadvantage over `Array`:

* 1 level of indirection in `resetTokens` / `resetComments`. You have to read the index, then index in to `cachedTokens` array to get the `Token` object, in order to reset it.

The latter will only have a significant effect when there's a large number of tokens/comments to reset. We avoid this in the worst case where *all* tokens have been deserialized (e.g. by accessing `ast.tokens`). When `allTokensDeserialized === true`, `resetTokens` just loops through `cachedTokens` itself, and ignores the `Uint32Array` entirely.

## Future potential optimizations

It's probably not necessary to reset all tokens quite so aggressively when all tokens have been deserialized. If a rule has done that on 1 file, chances are it'll do it again on the next file, at which point most `Token`s get their `value` property overwritten with slices of *that* source text anyway.

It's acceptable for source texts to hang around in memory for a bit, just not forever. We could choose to do token resetting only e.g. once every 10 files, to reduce the cost.

Possibly clean-up operations could also run in next tick, so they happen in parallel while Rust side is prepping the next file to send over to JS, rather than blocking.