Pass the build's versions to the examples MSBuild call

[lahma]

Fixes the build-windows regression from #351. CompileExamples currently fails with:

error CS1705: Assembly 'Spring.Messaging' with identity 'Spring.Messaging, Version=3.1.0.0'
uses 'Spring.Core, Version=3.1.0.0' which has a higher version than referenced assembly
'Spring.Core' with identity 'Spring.Core, Version=1.0.0.0'

Cause

Four example solutions include the src/Spring projects directly rather than referencing built output:

examples/.../Spring.Northwind.sln                  <- built by CompileExamples
examples/.../Spring.Scheduling.Quartz.Example.sln  <- built by CompileExamples
examples/.../Spring.WebQuickStart.sln              <- skipped
examples/.../SpringAir.sln                         <- skipped

So MSBuild /target:Restore;Rebuild on those recompiles Spring.Core and friends straight back into build/$(Configuration)/. That call passed no version properties, so the rebuild stamped the SDK default 1.0.0.0 over what CompileSolution had produced.

While every assembly was 1.0.0.0 this was invisible — the versions were uniformly wrong, so nothing conflicted. Now that CompileSolution sets real versions it is a hard failure: build/Release/Spring.Core/net462/Spring.Core.dll gets clobbered to 1.0.0.0, while the copies already distributed into the other projects' output folders during CompileSolution are still 3.1.0.0. The CI log shows exactly this — Northwind builds first and clobbers, then MsmqQuickStart hits the conflict:

MSB3277: There was a conflict between "Spring.Core, Version=1.0.0.0" and "Spring.Core, Version=3.1.0.0".
  "Spring.Core, Version=1.0.0.0" ... [build\Release\Spring.Core\net462\Spring.Core.dll]
  "Spring.Core, Version=3.1.0.0" ... [build\Release\Spring.Messaging\net462\Spring.Core.dll]

Fix

Apply the same versions to the examples MSBuild invocation, so every path that writes into build/ agrees. MSBuildSettings has no VersionPrefix/VersionSuffix setter, so those two go through SetProperty.

Verification

CompileExamples cannot run on this machine (VS 2022's MSBuild 17.14 cannot load SDK 10.0.302 projects — CI uses VS 18), so the mechanism was reproduced directly with dotnet build on the Quartz example solution, which takes the same path:

BEFORE                          : 3.1.0.0
AFTER build WITHOUT version args: 1.0.0.0   <- reproduces the bug
AFTER build WITH version args   : 3.1.0.0   <- fixed

The emitted command line now carries them:

msbuild.exe ...Spring.AopQuickStart.sln /target:Restore;Rebuild /p:Configuration=Release
  /p:AssemblyVersion=3.1.0.0 /p:FileVersion=3.1.0 /p:VersionPrefix=3.1.0 /p:VersionSuffix=dev-20260809-0956

build-windows on this PR is the real check, since it is the only place CompileExamples actually runs.