FileBasedProgramsProjectSystem should only initiate design-time builds on project-related text content changes

[RikkiGibson]

I think this implementation is kicking a new design-time build on each edit to the app.cs file. In follow-up PR we should probably make sure that a new design time build is only kicked if directives change, or if files that may be part of the project are added/removed, etc. Not for changes to ordinary source code, I think.

Originally posted by @RikkiGibson in #78488 (comment)

[RikkiGibson]

I started to implement this by storing a checksum of the virtual project XML that we got back from run-api, and declining to update when it was unchanged.

This doesn't really work because all kinds of file changes can cause the meaning of the design time build to change, including changes to props files and project assets files from restore.

I am wondering if dotnet run-api itself could help us solve this, as the SDK is doing significant amount of work already to avoid calling msbuild when it decides there is not a need to.

If IDE could be told the most recent checksum or timestamp or what have you for the effective set of run-file inputs, including all the Directory props files and so on, then we could prevent unnecessary reloads by simply tracking when that "full" checksum changes, and only running our design-time build (after the very first one) when we notice the checksum has changed.

As-is, the project system thinks of the app.cs file as also being the project file, and it simply says: oh, it changed. Better reload. Always. Causing many unnecessary restore popups, etc.