Do not calculate signatures if old state is not used

[sheetalkamat]

Changes in this:

1. If the old state was not present or not used, we set flag that says instead of calculating signature for a file (which is dts emit hash) use the version of file as the signature.
2. This makes it so that initial compilation will not calculate the d.ts emit and next file change to the file will be treated as non local change and thats when the signatures for file reference dependency are calculated and it would probably result in emitting more files than necessary but thats the compromise for not having to spend cost for d.ts emit in the initial round. The next change to that file should be able to correctly detect local/non local change as before.

925e70e Just updates tests to ensure we are testing the scenarios we intended.
dd1cef2 is actual change and may be ideal to look at the changes as part of that commit.
69ebfe3 Checks updates to the incremental correctness of the program, essentially signature is same as d.ts emit signature or version of the file. Also exported modules map is checked in similar way.
44ba0ec Reverts the compileOnSave to old behavior of always computing signature

This is simplified implementation of work in #42960 by @sokra
There are more todos that we can improve on, eg if global file is changed, mark it for lazy signatures etc but i think that each change should be separate change to be able to evaluate the perf impact and if needed revert it.
Potential improvements:

1. Global file change => resulting in emitting all files so could benefit from using signature as version
2. Certain number of new files percentage
3. Certain number of changed file percentage

[sheetalkamat]

I wonder if compileOnSave should disable this behavior given it doesnt save all files so will be anyways calculating signatures for affected set and not going to change from one edit to next ?

[sheetalkamat]

@uniqueiniquity @jessetrinity @amcasey thoughts ?

[amcasey]

@sheetalkamat Can you please elaborate? I think you're saying

1. Old behavior: compute (emit?) .d.ts on compile-on-save
2. New behavior: don't compute (emit?) .d.ts on (first?) compile-on-save
3. Proposed behavior: restore old behavior

[uniqueiniquity]

If @amcasey's explanation is correct, then yes - my instinct says that compile-on-save should compute+emit .d.ts.

[sheetalkamat]

Yes thats what i meant.. i will revert to old behavior for compile on save

[sheetalkamat]

Updated and ready for review

[amcasey]

Does this make the first watch build as fast as a non-watch build or is there still some overhead?

[sokra]

Does this make the first watch build as fast as a non-watch build or is there still some overhead?

yes, it should be about as fast. There is probably still an overhead, but it's unnoticeable.

[sokra]

I did some basic benchmarking and it works as expected for the usual cases.

[sokra]

The following unusual case is still slow: Broken config file, compile, fix config file, compile.
It's like adding a lot of files and causes a lot of signatures to be computed. But this can be solved in a follow-up PR.