Framework code should not depend on IsDevelopment

### Is your feature request related to a problem? Please describe.
I found that I had to manually check for the appropriate environment name(s) to enable [user secrets](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets) in my application. ASP.NET Core only enables user secrets if the currently running environment is named "Development" and therefore require custom implementation to enable if your team does not use the same naming conventions as has been predefined by ASP.NET Core.

The code snippet in question: https://github.com/dotnet/aspnetcore/blob/d7187b01e87761c778a5c406802e8bfd9451f3cf/src/DefaultBuilder/src/WebHost.cs#L176-L183

`IsDevelopment` and its sibling extension methods are used internally in ASP.NET Core to enable/disable certain features when running the application in different environments. I suspect some 3rd party libraries do so likewise (although I have no experience with such). This helps a developer setting up their local environment for better debugging capabilities etc., while avoiding enabling those same features in production environments as they may be unsafe/unfit for a production application.

Personally, I would consider a development environment to not only be the developers local machine but could just as well be a server-hosted application shared by multiple developers where the application is deployed prior to a "test" environment. As such two environments may (and very likely will) use a different configuration setup while still enabling certain debugging features, having only one name for what constitutes a "development" environment limits or completely disables the help provided by ASP.NET Core out of the box.

### Describe the solution you'd like
To combat the issue described above I would suggest allowing the developer to define when `IsDevelopment` etc. should return `true`. This could be done e.g. through a configuration variable similar to `ASPNETCORE_ENVIRONMENT` (say `ASPNETCORE_DEVELOPMENT_ENVIRONMENTS`) that takes a comma-separated list of names considered to be a "development" environment. Alternatively, instead of implementing `IsDevelopment` etc. as extension methods they could be implemented such that they're overridable.

### Additional context
I noticed #26539 has already brought this up but was closed. However, I believe the feature request deserves a bit more consideration with some additional context. Hopefully I provided that.

Start with src/DefaultBuilder/src/WebHost.cs at the referenced lines and trace how IsDevelopment is used to enable user secrets. Read the linked user-secrets documentation and prior issue #26539, then review the comment history for an agreed direction. Done requires a settled approach for recognizing non-Development environment names without unsafe production behavior.

Written by the indexing model from the issue text.