Resolve the content builder paths from the build instead of assuming bin/Debug

[tanguychenier]

Fixes MonoGame/MonoGame#9486.

The defect

BuildContent.targets builds two paths by writing $(ProjectDir) straight in front of $(OutputPath) and $(IntermediateOutputPath), and points at the content builder through a hardcoded bin\Debug folder. Both hold only for the default output layout.

With UseArtifactsOutput the SDK makes those two properties absolute and moves the executable under artifacts/bin. Measured on a project with and without the property, same SDK:

	default layout	artifacts layout
$(OutputPath)	bin/Debug/net9.0/	/src/artifacts/bin/app/debug/
$(ProjectDir)$(OutputPath)	/src/bin/Debug/net9.0/	/src//src/artifacts/bin/app/debug/
bin\Debug\<builder>	exists	does not exist

So the Exec call becomes:

/src/Game.Content/bin/Debug/Game.Content build -p DesktopVK \
  -o /src/Game.DesktopVK//src/artifacts/bin/Game.DesktopVK/debug/ \
  -i /src/Game.DesktopVK//src/artifacts/obj/Game.DesktopVK/debug/

and the build stops with exit code 127 before a single asset is built.

The change

Paths are composed with Path.Combine, which returns the second argument when it is already absolute and joins otherwise, so both layouts come out right. Measured on the same project:

	default layout	artifacts layout
Path.Combine($(ProjectDir), $(OutputPath))	/src/bin/Debug/net9.0/	/src/artifacts/bin/app/debug/

The executable is taken from the TargetOutputs of the MSBuild task that has just built the content project, rather than assumed. That also stops depending on AppendTargetFrameworkToOutputPath being false, which is what made bin\Debug\<name> work until now.

The three copies of the file in the templates carry the same two lines, so all three are updated.

Verification

A project generated from mg2dmgcbstartkit, with UseArtifactsOutput set to true, built for DesktopVK:

template	result	assets built
current	exited with code 127	0 .xnb
this branch	Build succeeded	54 .xnb

The same test with the default layout succeeds on both, and the resolved command line is byte for byte what it was before, so nothing moves for projects that do not use the artifacts layout.

I also ran it against the reporter's own reproduction, distantcam/ContentBuilderExample, with the same outcome, and checked that the generated content lands in artifacts/bin/<project>/debug/Content where the game looks for it.

One thing worth knowing, unrelated to this fix: the content project is not part of the generated solution, so a plain dotnet restore does not cover it and the first build stops on NETSDK1004 until it is restored once. That happens in both layouts. Happy to open a separate issue if you would like it addressed.