perf(compiler): use moduleResolutionCache for Language Service's resolveModuleNames

[ahnpnl]

Summary

#1784 introduced the usage resolveModuleNames API from LanguageService. I noticed that resolveModuleNames API can have a cache called ModuleResolutionCache so I went ahead and tried out. The result is amazing:

• Before fix(compiler): use resolveModuleNames TypeScript API to get resolved modules for test files #1784 and after fix(compiler): use resolveModuleNames TypeScript API to get resolved modules for test files #1784: the performance is more less similar, sometimes fix(compiler): use resolveModuleNames TypeScript API to get resolved modules for test files #1784 makes performance even worse.
• With this PR: the performance is even better than before fix(compiler): use resolveModuleNames TypeScript API to get resolved modules for test files #1784 and after fix(compiler): use resolveModuleNames TypeScript API to get resolved modules for test files #1784

Some figures

Testing against my company's project which has 2k+ test files as well as the repo source has 2k+ files.

After #1784

 PASS  src/__tests__/pulse-items/pulse-items-filter.helper.spec.ts (5.736s)
 
 PASS  src/__tests__/hybrid-apps/widget-card-settings.handler.spec.ts (21.57s)
 
 PASS  src/__tests__/pulse-items/pulse-items-ws-res.handler.spec.ts (31.41s)
 
 PASS  src/__tests__/inbox/inbox-detail-traveller.effects.spec.ts (31.892s)
 
 PASS  src/__tests__/task-viewer/task-viewer.effects.spec.ts (31.972s)
 
 PASS  src/__tests__/shared/numeric-field.component.spec.ts (22.818s)

 PASS  src/integration-tests/inbox-message-view/email-custom-action.spec.ts (18.773s)
 
 PASS  src/integration-tests/inbox-message-view/email-standard-action.spec.ts (15.707s)

With this PR

 PASS  src/__tests__/pulse-items/pulse-items-filter.helper.spec.ts (5.387s)

 PASS  src/__tests__/hybrid-apps/widget-card-settings.handler.spec.ts (12.154s)
 
 PASS  src/__tests__/pulse-items/pulse-items-ws-res.handler.spec.ts (19.322s)
 
 PASS  src/__tests__/inbox/inbox-detail-traveller.effects.spec.ts (20.206s)
 
 PASS  src/__tests__/task-viewer/task-viewer.effects.spec.ts (19.916s)
 
 PASS  src/__tests__/shared/numeric-field.component.spec.ts (20.487s)
 
 PASS  src/integration-tests/inbox-message-view/email-custom-action.spec.ts (13.759s)
 
 PASS  src/integration-tests/inbox-message-view/email-standard-action.spec.ts (11.163s)

Some tests gain huge performance boost and overall, the time to execute the tests for the whole project improved about 20%-30%.

The difference in time between no cache run and cache run reduces to no-cache run = x1.5-2x cache run comparing to no-cache run = 2x-2.5x cache run after #1784

Test plan

Added unit test for checking the usage of ts.createModuleResolutionCache. Green CI

Does this PR introduce a breaking change?

• Yes
• No

Other information

I also correct test for config-set.ts which reduced coverage in #1784

[coveralls]

Pull Request Test Coverage Report for Build 5297

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.07%) to 92.83%

---

Totals
Change from base Build 5296:	0.07%
Covered Lines:	1056
Relevant Lines:	1091

---

💛 - Coveralls