For composite projects with --out write tsbundleInfo file and use it to process shebang, prologues and other information

[sheetalkamat]

This is another version of #29582 and would be helpful to enable --stripInternal by recording those sections and not emitting those portions on final projects with --stripInternal (eg. generating typescript.d.ts)
Fixes #25550

[weswigham]

@sheetalkamat Could we have both methods of looking up the metadata in place? The bundle info is nice for build pipelines that only use tsc -b, but it's very possible that in more complex pipelines the build intermediate outputs could be munged by other tools (and we don't keep an incremental cache of our own to rely on), in which case the .tsbundleinfo data would be out of date and the information would need to be recalculated from the sources anyway.

[sheetalkamat]

@weswigham we are call host.readFile and host.writeFile so any kind of build chains should have no issues with this right? Wouldnt we want host to implement those details. Having second method of retrival is easy but that just adds another code path we need to maintain and test. Is it really necessary?

[weswigham]

@sheetalkamat I'm thinking more along the lines of build chains that just shell out to tsc -b, where they execute it once, then do another transform on the output (like minification, webpacking, or API-extracting), and where that secondary transform may be done in-place (although in those situations, most of our assumptions about our ability to reuse the outputs is out the window anyway tbh).

[sheetalkamat]

@weswigham I had chat with @RyanCavanaugh and we think at this moment the fall back parsing isn't necessary.
We also discussed .tsbundleinfo being more information than just --out so instead of naming it as outFile.tsBundleInfo it should just be .tsbundleinfo and I will update the branch with that.

[sheetalkamat]

I am going to close this and open PR that is bigger set of changes where prepend mapping works much better.