* Refactoring so CacheWithRedirects has Key and Value type parameters
* ModuleResolutionCache or TypeRefDirectiveCache will look in directory before solving, so ResolutionCache doesnt need this check
* Test showing module resolution is not shared because resolution cache doesnt update own options
* Enable traceResolution on some of the project reference tests
* Simplify CacheWithRedirects and ensure the options are set in all common scenarios so cache can be shared between redirects
* Make failedlookup etc optional in ResolvedModule/TypeRefefWithFailedLookupLocations
Also make accidental public failed lookup internal
* Add new API for module and type ref resolution
* Store auto type reference resolutions
* Modify test to show how using program partially doesnt report resolution diagnostics
* Ensure that resolution diagnostics are reported in filePreocessingDiagnostics so they can be reused when program is reused
* Some cleanup
* Remove the newly added ReoslutionInfo in favor of new APIs
* update
* Refactoring so CacheWithRedirects has Key and Value type parameters
* ModuleResolutionCache or TypeRefDirectiveCache will look in directory before solving, so ResolutionCache doesnt need this check
* Test showing module resolution is not shared because resolution cache doesnt update own options
* Enable traceResolution on some of the project reference tests
* Simplify CacheWithRedirects and ensure the options are set in all common scenarios so cache can be shared between redirects
* Add tests where typeRef resolution is not in the cache
* Ensure that type ref reuse is actually handled since type ref resolution only sends containingSourceFileMode and not containingSourceFile
This adds a "small" d.ts bundler script. This script is very basic,
using Node printing to produce its output. Generally speaking, this is
inadvisable as it completely disregards name shadowing, globals, etc.
However, in our case, we don't care about the globals, and we can opt to
restructure our codebase in order to avoid conflict, which we largely
had to do anyway when we were namespaces and everything was in scope.
If these are regular comments, then they won't appear in our d.ts files.
But, now we are relying on an external d.ts bundler to produce our final
merged, so they need to be present in the "input" d.ts files, meaning
they have to be JSDoc comments.
These comments only work today because all of our builds load their TS
files from scratch, so they see the actual source files and their
non-JSDoc comments.
The comments also need to be attached to a declaration, not floating,
otherwise they won't be used by api-extractor, so move them if needed.
This step converts as many explicit accesses as possible in favor of direct imports from the modules in which things were declared. This restores the code (as much as possible) back to how it looked originally before the explicitify step, e.g. instead of "ts.Node" and "ts.Symbol", we have just "Node" and "Symbol".
