build member tables of instantiated classes/interfaces lazily

[Max Schwenk (maschwenk)]

Part of #64474 (#64499 fixed the intersection half)

looking up one property on an instantiated class or interface builds the whole member table right now. every declared member gets instantiated and every inherited one gets merged in, even though most of them never get used. a few shape checks (isWeakType, getSingleSignature, isStringIndexSignatureOnlyType, isFunctionObjectType) do the same thing just to count stuff

this gives such a reference a lazy member table instead. setting it up does what resolveObjectTypeMembers does in the same order, except creating the member symbols. signatures and index infos get instantiated and inherited as usual, through a helper resolveObjectTypeMembers now shares, so getSignaturesOfStructuredType and getIndexInfosOfStructuredType can answer from the table. member lookups only instantiate the member that was asked for, and if the full table gets built later it reuses whatever was already handed out, so symbol identity doesnt change

the shape checks read through those accessors plus getMemberOfStructuredType, hasPropertiesOfStructuredType and everyPropertyOfStructuredType, so each check is still written once. the lazy lookups alone dont save anything since the shape checks would build the full table right away, those are what make it pay off

whether instantiateSymbol hands back the original symbol depends on what's been resolved so far, so the table records that when it's set up. with #64372 in, that's the only thing it has to copy. while a table is being set up the type just resolves its members the normal way

history: the first version (up to af2719b) had a separate lazy copy of each shape check, cdac4e3 reworked it to go through the accessors, and after merging main 39ce30c drops the half built member handling #64372 made unnecessary. its +344/−37 in checker.go now (was ~570), the rest of the diff is two tests and their baselines

this PR vs main at 0681ef7 (so with #64372 and #64499), typescript-benchmarking, median of 3:

	heap, 4 checkers	peak rss, 4 checkers	check, 4 checkers	heap, single	check, single
vscode	−8.9%	−5.0%	−2.1%	−7.7%	−2.5%
xstate-main	−9.0%	−7.0%	−5.2%	−6.7%	−1.5%
webpack	−8.6%	−1.9%	−5.7%	−6.0%	−2.3%
Compiler	−4.5%	−2.1%	−1.4%	−1.6%	+0.6%
Compiler-Unions	−2.5%	−0.3%	+1.8%	−2.1%	+0.8%
mui-docs	−1.3%	+0.1%	+1.7%	−1.4%	+2.2%

on our 37k-file program, also on 0681ef7: heap 19.1 → 15.4 GiB with 4 checkers (−19%) and 12.6 → 10.6 GiB single threaded (−16%), check time −7% single threaded. same diagnostics on every run. raw results and scripts: https://gist.github.com/maschwenk/c83d9185c6961b6fb43d7d071ef39cf6

full go suite passes (also multiple checkers and -race), lint and format are clean. added instantiatedReferenceMemberLookup.ts and instantiatedReferenceShapeQueries.ts with baselines generated on unmodified main, so they pin that the output didnt change

• associated issue: checker builds member tables and intersection props it never uses #64474
• up to date with main
• tests pass (go test ./... in tsc, same thing hereby test runs)
• hereby lint
• hereby check:format
• new tests

used claude code to help write this, ive reviewed it

[Anders Hejlsberg (ahejlsberg)]

Max Schwenk (@maschwenk) I definitely want to land #64499, really nice savings from that one. Once it is in, let's see how much extra savings we can get from this one. I'm a bit concerned with adding ~500 lines of code to member resolution.