Add IHostApplicationBuilder support to the C# generichost generator

Problem

The generichost library generates DI wiring extension methods only for IHostBuilder (via ConfigureApi on the host builder) and IServiceCollection (via AddApi). Both are built around the legacy generic-host model that starts from Host.CreateDefaultBuilder(args).

Modern .NET has moved on. Since .NET 8, the recommended and template-default way to bootstrap an app is the streamlined Host.CreateApplicationBuilder() / WebApplicationBuilder model, which exposes an IHostApplicationBuilder. Microsoft's own guidance describes the older IHostBuilder approach as a legacy pattern kept for compatibility, while IHostApplicationBuilder is "recommended for new projects and is the default in current .NET templates."

Consumers on that modern hosting model had no first-class way to register the generated client. They were forced to drop down to builder.Services.AddApi(...), or hand-roll their own IHostApplicationBuilder extension method — which defeats the purpose of a generated SDK. This was raised in #23595.

Solution

The generator now emits an IHostApplicationBuilderExtensions class alongside the existing extensions, providing a ConfigureApi overload that hangs directly off IHostApplicationBuilder:

var builder = Host.CreateApplicationBuilder(args);

builder.ConfigureApi(options =>
{
    options.AddTokens(new BearerToken("<your token>"));
});

var host = builder.Build();

The new method mirrors the existing surface exactly: it constructs a HostConfiguration, invokes the caller's configuration delegate, and forwards to the same IServiceCollectionExtensions.AddApi core registration. As a result, every existing extensibility hook (OnHostConfigurationCreated, OnAddApiHttpClientBuilder, OnServicesAdded) fires identically no matter which entry point a consumer uses — there's a single registration path, just three different front doors.

The signature intentionally follows idiomatic .NET DI conventions and stays consistent with the sibling AddApi(this IServiceCollection, Action<HostConfiguration>) overload: a single configuration delegate, with the builder returned for fluent chaining. Anyone needing the raw IServiceCollection still has it directly as builder.Services.

Because Host.CreateApplicationBuilder() and the IHostApplicationBuilder interface only exist on .NET 8+, the generated class is gated behind the net80OrLater flag so older target frameworks (net6/net7) are unaffected. The README usage sample follows the same gate, showing the modern Host.CreateApplicationBuilder() pattern for net8+ projects and the existing IHostBuilder pattern otherwise — one canonical example per generated project, always matching the target framework.

Closes #23595.

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

---

Summary by cubic

Adds IHostApplicationBuilder support to the C# generichost generator so .NET 8+ apps using Host.CreateApplicationBuilder() can register the generated client via a new ConfigureApi extension instead of falling back to builder.Services.AddApi(...). The extension forwards to the existing IServiceCollectionExtensions.AddApi registration path, keeping extensibility hooks identical regardless of entry point, and is only emitted for net80OrLater targets. Closes #23595.

New Features

• Emits an IHostApplicationBuilderExtensions class with a ConfigureApi overload, gated behind net80OrLater so older target frameworks are unaffected.
• README usage samples now show Host.CreateApplicationBuilder() for net8+ targets and keep the IHostBuilder pattern for older ones.