Test projects using Aspire.Hosting.Testing on net9.0 run on newer MS.Extensions.* packages than the app host projects they're testing

[DamianEdwards]

In order to unblock PR #6419 that ensures templates bring in the supported version of Microsoft.Extensions.Http.Resilience (i.e. 9.0 as it ships out of dotnet/extensions which has a "tip only" support policy), Aspire.Hosting.Testing had to be updated to multi-target net8.0 and net9.0 and bring in the relevant version of Microsoft.Extensions.* packages, i.e. 8.x if targeting net8.0 and 9.x if targeting net9.0, as those packages follow the STS/LTS support policy.

This has resulted in a situation whereby Aspire apps targeting net9.0 run on different versions of Microsoft.Extensions.Hosting (and it's friends like Microsoft.Extensions.Configuration, Microsoft.Extensions.Logging, etc.) when launching the app host project versus when they run tests based on Aspire.Hosting.Testing:

flowchart LR
    A[MyApp.AppHost] -->|net9.0| B(Aspire.Hosting.AppHost/9.0)
    B -->|net8.0| C(Aspire.Hosting/9.0)
    C -->|net8.0| D(MS.Ext.Hosting/8.0)
    C -->|net8.0| E(MS.Ext.*/8.0)
    T[MyApp.Tests] -->|net9.0| U(Aspire.Hosting.Testing/9.0)
    U -->|net9.0| C(Aspire.Hosting/9.0)
    C -->|net9.0| V(MS.Ext.Hosting/9.0)
    C -->|net9.0| X(MS.Ext.Hosting/9.0)

Loading

Running tests on a different version of Micorosft.Extensions.* than the app host project uses when running normally is far from ideal.

We should consider multi-targeting Aspire.Hosting.AppHost in the same way as Aspire.Hosting.Testing so that both the test and app host projects end up running on the same versions of Microsoft.Extensions.*.