Rename ConfigureHostApplicationBuilder to ConfigureWebApplicationBuilder

[Youssef1313]

Reacts to product change in dotnet/aspnetcore#67917

This will be ready to merge when the PR is merged and gets released in Preview 7 (if merged on time)

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/test/integration-tests.md	Integration tests in ASP.NET Core

[guardrex]

Hello @Youssef1313 ... Note in passing that the original content (and this change) probably isn't versioned correctly. We usually rely on the document version selector to present versioned content. Otherwise, we'd fill the articles with little versioning remarks like this ... several hundred of them by now for sure if we didn't avoid the practice. Articles would have little "this works in .NET X or later" or "support for this ended in .NET Y" remarks all over the place. The content should be set off in versioning monikers and not make any mention of the release version. It would go like the following IF Tom decides to drop the dreaded INCLUDES versioning approach 😄 ...

:::moniker-end

:::moniker range=">= aspnetcore-11.0"

3. You can override a new `ConfigureWebApplicationBuilder` method as follows:

... the rest of the versioned content ...

:::moniker-end

:::moniker range=">= aspnetcore-10.0"

If Tom keeps the INCLUDES file versioning approach, the entire article should be duplicated for .NET 11, and the line still shouldn't remark on .NET 11 or a preview release. Such remarks that refer to release versions typically only appear in release notes and migration content. Release notes and migration content can link to the 11.0 version of the article (and the section) with the following to surface the content ...

<xref:test/integration-tests?view=aspnetcore-11.0#customize-the-webapplicationfactory-with-test-configurations>

Anyway ... just mentioning all of this in passing ... Tom takes care of this particular article. He'll get back to you to let you know how he would like it handled. I've pinged him. Stand-by ....................