Support EF Core Migrations with Aspire’s Environment Configuration without Forcing WebApp Startup

Description
When running EF Core migrations in a .NET Aspire solution, we currently have to point at the WebApp project as the startup assembly. That means all our environment-specific service registrations (e.g., secrets, feature flags, custom DI modules) are only configured at runtime via the WebApp’s Program.cs. As a result, invoking dotnet ef migrations add or Update-Database against a separate class library or DbContext project fails to pick up our environment settings and service registrations.
We need a way to generate and apply migrations while still leveraging Aspire’s environment setup—without having to launch the full WebApp.

Expected Behavior
- Ability to scaffold and apply EF Core migrations in the Data project without pointing at WebApp.
- Design-time service provider should load the same environment configuration defined by Aspire (including secrets, feature flags, custom DI modules).
- A clear mechanism—like an IDesignTimeDbContextFactory override or an Aspire CLI flag—to bootstrap environment setup for migrations.

Impact
- Every developer or CI/CD pipeline must use the WebApp as startup, incurring longer startup times.
- Hard to isolate database changes in headless or containerized migration scenarios.
- Breaks separation of concerns between data layer and web host.

Proposed Solutions
- Document and expose an AspireDesignTimeHost that programmatically loads environment settings in a class library context.
- Provide a CLI option:
`dotnet aspire migrations add --context-project Data --migrations-project Data --environment` Development
- that handles both configuration and migrations.
- Offer a sample IDesignTimeDbContextFactory implementation in Aspire templates that wires up the environment as if the WebApp had run.