Free preProgram early in the test harness

[Andarist]

I'm investigating some OOMs and this helps with some test-only OOMs when the preProgram retains over half of the available space. When the final program gets executed it repeats the work done by the preProgram and tries to allocate roughly the same amount of memory. But this time the test harness OOMs given both combined exceed the node.js allowed heap space.

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[jakebailey]

Hm, I'm not seeing a benefit; this is psrecord --include-children --plot pr.png 'npm test -- --no-lint' before/after.

[Andarist]

You are profiling the whole test suite. This only makes the preProgram collectable early within a single test case - before the containing function exits. I was running into an OOM without this because the second program created by this function exceeded the available heap space (when the heap was still occupied by the preProgram as it was retained by the closure~).

[Andarist]

You can verify the above by:

• checking out d1633a1c44dd2423623bd52cad8224213ed5ebed
• running npx hereby runtests --tests="crossProductUnionIntersectionRepeatedPropDeclarationsNoOOM2" --no-lint --timeout 24000000 (it should complete way before the specified timeout but the chances it won't complete under default 40s are high)
• dropping 76748c2e028635047877960b392c6ab65b6b5125 (that's the cherry-picked commit from this PR)
• re-running the above test command. This time it should OOM

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate