[MEAI] IChatClient dependency extensions should support lifetimes beyond singleton

[eiriktsarpalis]

The IServiceCollection extensions provided with the MEAI package are hardcoding singleton lifetimes for registered services:

extensions/src/Libraries/Microsoft.Extensions.AI/ChatCompletion/ChatClientBuilderServiceCollectionExtensions.cs

Lines 28 to 38 in fab3675

	public static ChatClientBuilder AddChatClient(
	this IServiceCollection serviceCollection,
	Func<IServiceProvider, IChatClient> innerClientFactory)
	{
	_ = Throw.IfNull(serviceCollection);
	_ = Throw.IfNull(innerClientFactory);
	var builder = new ChatClientBuilder(innerClientFactory);
	_ = serviceCollection.AddSingleton(builder.Build);
	return builder;
	}

This doesn't work well in the context of Github Copilot agents that forward to the Github completions API since the clients need to be scoped to the specific Github token used in the request. We should consider extending the helpers so that all lifetimes are supported -- most likely this is going to be a breaking change since we'd need to rename the methods to adhere to naming conventions used DI elsewhere: AddSingletonChatClient, AddScopedChatClient, AddTransientChatClient, etc.

cc @stephentoub @SteveSandersonMS

[SteveSandersonMS]

This was pretty intentional - defaulting to "singleton" is required to align with Aspire conventions.

However EF's DI registration helper allows specifying an alternative lifetime as a parameter, e.g.:

builder.Services.AddDbContext<ITestDbContext, TestDbContext>(optionsBuilder =>
{
    optionsBuilder.UseSqlServer(ConnectionString);
}, contextLifetime: ServiceLifetime.Singleton);

(taken from dotnet/aspire#1194 (comment))

So perhaps we should add the same option.

[stephentoub]

So perhaps we should add the same option.

I like that much better than having a bunch of differently-named methods. If this is an acceptable pattern, either adding an optional ServiceLifetime parameter, or adding another overload that takes one, sounds like a really good answer.