Make serviceName in HttpClient builder extensions obsolete, add new overloads

[MattKotsenas]

Currently, the HttpClient builder extensions (i.e.
AddMicrosoftIdentityUserAuthenticationHandler and
AddMicrosoftIdentityAppAuthenticationHandler) take the service name as
the first parameter.

As far as I can tell, this value is only used to
name and subsequently retrieve the named options, all of which is
internal to the setup (or in other words, the user never needs to refer
to the client by this name).

Furthermore, these calls are always part of an .AddHttpClient() call,
which is also named, either explicitly, or implicitly with the type
name.

As a result, confusing or even incorrect use of the extensions is
possible when working with multiple clients. Consider a setup like this:

services
    .AddHttpClient("NamedClient1")
    .AddMicrosoftIdentityAppAuthenticationHandler("Service1",
	Configuration.GetRequiredSection("Service1"));

services
    .AddHttpClient("NamedClient2")
    .AddMicrosoftIdentityAppAuthenticationHandler("Service1",
	Configuration.GetRequiredSection("Service2"));

In this example, the HttpClient objects are named differently, and they
pull from different config sections, however due to a copy / paste
error, they both use the service name "Service1". In this case, despite
being two different builder chains and two different clients, the
configuration of Service1 will be overwritten by the values of Service2
because of the name collision.

In short, the service name appears to be unnecessary and a potential
source of confusion and bugs, as it isn't clear from the user's
perspective what it's used for.

In order to push users towards safer behavior while not making a breaking
change, we add new overloads that are missing the serviceName parameter,
and mark the existing methods as Obsolete.

[MattKotsenas]

As mentioned above, opening this to at least start a discussion around if it makes sense to remove the "serivceName" parameter, given that it seems redundant with the client name, and has confused some people on my team.

If there's agreement on removing it, I defer to the team about how best to communicate that (i.e. major version bumps, additional overloads, obsolete annotations, etc.) but didn't want to get ahead of myself before there's conensus.

Also tagging @qetza , who wrote the initial implementation, in case there are uses I'm missing.

Thanks!

[MattKotsenas]

Hey there! Friendly ping to see if this is a change worth considering. Also pinging @jennyf19 for visibility.

If you have any questions, please let me know. Thanks!

[jennyf19]

Hi @MattKotsenas This would be a breaking change for us, so not sure if we want to do that atm. @jmprieur for perspective.

[MattKotsenas]

Oh yes, as-is definitely would be a breaking change. I think the first question is "is this something you would ever accept?", since I don't see a purpose to name the service config, but that doesn't mean there is no purpose :-P

If so, then we can focus on either how to land a breaking change, or if there's something we'd want to do to make it not blocking (i.e. new overrides or marking deprecated). Let me know if that makes sense, or if you have questions!

[jmprieur]

Proposing a simpler change for the same effect

[MattKotsenas]

Thanks @jmprieur! I believe I updated this change as you suggested; would you mind taking another look and letting me know if there are any questions or concerns? Thanks!