Update to .NET 8, remove x64 limitation, change to FAKE build project

[florenzen]

• The code base is updated to use .NET 8.
• The packages can be referenced on other architectures than x64. Since the underlying solver libraries provide native runtimes for other architectures and operating systems, this restriction is not necessary.
• To leverage the power of Ionide in a more straight-forward way and to overcome some limitations of the FAKE runner wrt. dependencies, the build script now resides in a build project and is invoked via dotnet run in build.sh/build.cmd.
• Update the reference to Google.OrTools to the latest 9.x version.

[smoothdeveloper]

@florenzen I believe the library projects should still target netstandard2.0, unless the libraries make use of dotnet 8 specific things, or references packages that only support dotnet 8, otherwise it won't be possible to use the project on .net framework.

Updating the repository itself (such as build and test projects, etc.) to dotnet 8 makes sense though.

[florenzen]

Thanks for that feedback @smoothdeveloper. Since I also updated the references to the Google.OrTools packages targeting netstandard2.0 gives

.../flips/Flips/Flips.fsproj : warning NU1701: Package 'Google.OrTools 9.9.3963' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

as the newer releases of Google.OrTools do not provide netstandard2.0 builds anymore.

An alternative would be a multi-target build addressing net8.0;net462 with net462 being the framework version required by OrTools.

I forgot to mention the reference update in the PR description - I just fixed that.

[smoothdeveloper]

Mmh, I see Google.OrTools would need net60.

Ideally we'd split the reference from the core project and have separate asssembly for the OrTools implementation.

I think the recommendation remains to use the lower target that fits the bill, net60 & net462 if everything is fine.

It won't affect end users that want to target higher versions.

[florenzen]

I changed the target frameworks for the Flips library and package to net6.0 and net462 as you suggested.

In my understanding, separating the Google.OrTools dependent part and consequently also the Optano dependent part would only help if there are no static references to the external packages anymore. As a consequence, this would involve dynamic loading of these libraries, depending on the solver type chosen, and the end user being responsible to have the required libraries available. This would amount to a major rewrite of the Flips package.