Refactor fs (cache/tracing) layer into self-contained API

[cspotcode]

trafficstars

We have multiple codepaths which both duplicate FS access code. Additionally, our source-map-support hook touches this FS caching layer.

Refactor into a single fs API which can be instantiated by a factory like createFsLayer() or createFsHost() and then used in all codepaths.

Having this layer may make future features, such as caching, easier to understand. For example, the fs layer can perform all writes into a cache, and all reads from either the cache or real filesystem, whichever is hit first.

[frank-dspeed]

Wouldn't it be better to implement something like resolve? i mean pre resolved stuff and do not modify the cache? I think the best place to solve all that issues is the resolve part inside TS we need a way to supply configuration for that and there are hooks implmented in TS for custom reslovers i am not aware if they are exposed or not

But i think its worth investigation into that direction maybe that algins some how with import map support.

[cspotcode]

I think we're talking about different things. For FS caching, necessary to take advantage of --incremental, we need a way to persist what the compiler attempts to write to the filesystem without interfering with normal tsc invocations.