When some projects target net7.0, and their dependencies dual-target net6.0, net7.0, cracking doesn't work

[safesparrow]

Describe the bug
Given a two-project setup:

1. A.fsproj targets net6.0, net7.0,
2. B.fsproj targets net7.0 and references A.fsproj

ProjInfo defaults to net6.0 for A, and net7.0 for B.
B's -r arg points to a net7.0 ref assembly, but FSharpOptions for A use net6.0, so there is no match and reference isn't loaded by FCS.

To Reproduce
Steps to reproduce the behaviour:

1. Checkout https://github.com/giraffe-fsharp/Giraffe
2. Crack Giraffe.sln using the following code

open System
open System.IO
open Ionide.ProjInfo

let slnPath = @"c:\projekty\fsharp\samples\Giraffe\Giraffe.sln"
let slnDir = Path.GetDirectoryName(slnPath)
let toolsPath = Init.init (DirectoryInfo(slnDir)) None
let globalProps = [ "Configuration", "Debug" ]
let workspaceLoader = WorkspaceLoaderViaProjectGraph.Create(toolsPath, globalProps)
let projects = workspaceLoader.LoadSln(slnPath)
let fcsProjects = FCS.mapManyOptions projects |> Seq.toArray

5. See in a debugger that the ReferencedProjects shows A.fsproj using net6.0:
   
   while OtherOptions section shows a reference to a net7.0 ref dll.
   

This causes a mismatch and results in not loading the referenced project.

Expected behaviour

Project options should be internally consistent and allow for project references to be recognised by FCS.

Environment (please complete the following information):

• OS: Win11
• Ionide version: Ionide.ProjInfo.FCS 0.63.0
• dotnet SDK version: 8.0.101

[baronfel]

I'm pretty sure this is a consequence of our 'first TFM wins' approach to ordering here. The minimal workaround would be to swap the order of TFMs in A.fsproj, but of course that won't work as a general solution.

A proper treatment would likely have to include us redoing our handling of multi-targeted projects - they don't really have a sensible default for OutputPath and other related properties - instead those properties should only ever be valid at a single-TFM level.