This was kzu's project[1] which had a very interesting goal:
make nuget restore be part of the build process itself (kind of
like a PreBuild target so that your IDE did the restore before
building, regardless if the IDE had nuget support or not).

Now, there's several reasons to remove it (ordered by level of
importance):

1. We're moving soon to dotnet v6 and newer, where a restore is
always assumed by the IDEs and command-line builds (the command
is even called "dotnet restore" itself, no need to specify
"nuget" anymore, as the term 'restore' has become part of the
dotnet jargon already).

2. Looking back, I introduced it in 2017 [2] but I kinda regret
doing it because of all the hacks (such as needing to generate
the special file 'before.$solutionFileName.targets before the
build) required to make it work, the ugliness of its code (not
really blaming the author here, maybe MSBuild's XML syntax is
generally unreadable), and:

3. The fact that despite the use of it, there were certain
sccenarios that needed an explicit restore of other solutions
or projects to make the build work with Xamarin.Forms.

So as there were explicit restores happening in make.fsx
anyway, let's make nuget restore explicitly handled now in all
cases by make.fsx (this quirk will not live very long anyway,
just as long as the Xamarin.Forms frontend lives, which is
getting replaced by MAUI soon).

This commit also disables nuget restore parallel processing
to prevent flaky nuget restore on mono.

[1] https://github.com/kzu/Nuget.Restore
[2] 9804b65

We renamed the project long time ago so it is about
time to follow suit with the solution file name.

This way they don't get confused with the main solution
(and still can be used by make.fsx to build with the command
line).

Updating links to scripts and Fsdk in main solution, and
deleting them on the others (since the others will only be used
for building now, not for using in the IDE).

This allows for building Backend and Frontend.XF with
separate build engine like .NET 6.

This commit allows for using legacy and non-legacy build
tools together to build GTK frontend without using MS's
binaries (newmono-msbuild).

It works by building .NETStandard project (that xbuild can't
build) using .NET6 and building GTK project using xbuild.

Co-authored-by: Afshin Arani <[email protected]>

Now that we removed [1] NuGet.Restore.targets, and NuGet.exe
gets downloaded by Fsdk via WebClient, I don't think we need
curl anymore.

[1] 04277ed

This commit alongside [1] allow for building GTK front-
end on this lane.

[1] 7f6c88d

Before this commit, we were assuming that legacy tools
were not present if dotnet was present. Now, if dotnet
is present, and legacy tools also are (so that the XF
frontend can be built), then make will build the frontend.

Obj path in some projects had to be changed like it was
done in [1] because building same project once with dotnet
and once with MSBuild causes problems (it happens in macOS
when both mono and dotnet exist).

[1] 6b3c64e

There have been some recent cosmetic commits so it's better to
group them here to avoid git-blame pollution.