FSharps use of CompileBefore for file ordering leads to issues with other SDK components

[KevinRansom]

@Smaug123 added a PR to sourcelink main: dotnet/sourcelink#1209

It highlights a long time issue with us relying on Compile before:

Snip:

SetEmbeddedFilesFromSourceControlManagerUntrackedFiles only considers files if they're in @(Compile). In an F# project, TargetFrameworkMonikerAssemblyAttributesPath is not in @(Compile) but is instead in @CompileBefore. The result is that the F# compiler never even attempts to embed obj/Release/netstandard2.0/.NETStandard,Version=v2.0.AssemblyAttributes.fs (for example), because it was never added to @(EmbeddedFiles).

It's possible that the correct fix is instead in Microsoft.FSharp.Targets. The behaviour of adding to CompileBefore rather than to Compile was added in 01c621c, which is extremely vague and dates back before pull requests and GitHub were a thing; so I can't find any of the context for it.

The likely fix is to modify our use of CompileBefore to adding Metadata to the Compile item that tells us to place the decorated item early in the build.

[Smaug123]

Given that #17057 was reverted in #17099, am I right in thinking this is not fixed?

[vzarytovskii]

Given that #17057 was reverted in #17099, am I right in thinking this is not fixed?

It was in #17103. Initial implementation broke file ordering in VS I think