Fix showing pars.fs, lex.fs output in solution view, fix auto-generating FsLex/FsYacc output on change, add fsl and fsy to solution view

[abelbraaksma]

Fixes #9919
Also fixes #9920

This fixes an issue partially caused by #9877, partially already present prior to that, which hid certain linked files because the <Link> element in fsproj didn't point to the solution folder, but to the source folder where the linked file came from.

Also fixes the somewhat annoying situation that when you change an fsl or fsy file, it doesn't get compiled. I've taken the liberty of slightly changing the link-structure (physical structure remains the same). By adding <None Include for those files, Visual Studio tracks them and MSBuild builds them.

Before (and after #9877):

After this change:

(note: I wanted to place the *.fsl/fsy input/output closer together, but the FsYacc and FsLex build tasks prevent this from happening. I.e., try moving UnicodeLexing.fsi up: you can't. I think this is the next best thing, let me know what you think ;) ).

Build now clearly shows that FsYacc (or FsLex) is run:

[abelbraaksma]

One more commit to apply the same idea to AbsIL. Moved lex/yacc outputs ilpars.fs and illex.fs up a little for easier discovery and because it was possible w.r.t. file-order dependencies.

Noted a very peculiar bug while working on this. If I use FsLexOut and FsYaccOut under ParseAndUntypedAST as the link-dir name, the solution explorer shows them wrongly on top. If I use any other name, like FsLexOutput, it is shown in the right spot.

This didn't happen on the first change. I tried several things like removing the fsproj.user file and restarting VS, it still acts weird.

With FsYaccOutput as virtual dir name:

With FsYaccOut as virtual dir name (order in fsproj file unchanged):

Just as strange: it only seems to apply that that specific part of the solution, I cannot repro it anywhere else. This may be a glitch of my system, but I've changed the virtual output dirs nonetheless.

Note that the out-of-order display in Solution Explorer had no effect on the ordering for MSBuild/fsc.exe.

Would be interesting to know if others can repro this:

• Change the mentioned virtual dirs FsLexOutput --> FsLexOut and FsYaccOutput --> FsYaccOut (around line 371, 383)
• Unload & reload the FSharp.Compiler.Private (or don't, the change to the tree structure is reflected directly).
• Check under ParserAndUntypedAST, the order of the dirs should remain unchanged (but changes as above in my case)

[abelbraaksma]

Since no code has changed, this will be green soon ;).

Here's a summary of what's changed w.r.t. experience:

• A Rebuild from Visual Studio now works correctly: it does recompile the fsy/fsl files. Previously, this wasn't the case.
• A normal Build from Visual Studio will now compile the fsy/fsl files, but only when dirty, i.e., changed on disk. Previously, they were never compiled, unless from commandline.
• The tree structure now contains both the input fsy/fsl files and the output pars.fs/lex.fs and related files, each in their own virtual directory.
• All changes are "virtual": it adds <None> for discovery, and a few wrongly named virtual dirs are now correctly named (see screenshots). There's no change to the overall build.cmd (except for correctly rebuilding from Visual Studio).

[abelbraaksma]

@cartermp, I think this is ready for merging, though @KevinRansom maybe you could have a quick look as well? You recently made changes in the same area...

[cartermp]

Thanks!