csc caching for file-based apps doesn't consider non-.cs default items, e.g. *.razor, leading to false cache hits

The optimization to `dotnet run` for file-based apps that avoids calling through MSBuild does not play well with apps that include non-.cs default items, e.g. file-based apps using the web SDK that have *.cshtml* or *.razor* files. These files will be auto-included as items by the SDK targets due to file-based app's support for default items, but changes to the set of files during the inner-loop will not result in a cache-miss (e.g. changing a file name, adding a new file, etc.) and thus runs will be out-of-date with the latest source until a run is done with the `--no-cache` flag.

We should consider options to improve the situation. We could try and disable the caching when non-default but "compile adjacent" items are detected (not sure how, but the point is files like `*.cshtml` and `*.razor` emit *.cs* files via a source generator, hence they affect compilation but aren't `` items), or, even better, figure out how to robustly include them in the cache calculation (again, no idea how, this one might be impractical as they're added via globs in the SDK which would need to flow through to `dotnet run` so that it could re-evaluate whether the result of the glob has changed between runs, and at that point it feels like we're likely over the line of doing **too** much that MSBuild already does, just to avoid it). Perhaps it's ok to special-case **.cshtml* and **.razor* when the Web/Razor SDK is detected given how tied they are to the compiler now anyway.

/Cc @baronfel @jjonescz