[MEVD] DI registration method changes

[roji]

• Our current DI Add* APIs - e.g. AddSqliteVectorStore - currently accept a string? parameter for the service key; but in the DI APIs (e.g. AddKeyedTransient), it can be anything (object?). I don't think MEVD connectors should arbitrary limit service key types to string when the general DI APIs allows object here.
• The naming here should be serviceKey, not serviceId - this is what it's called in the DI APIs.
• We should align to the standard .NET (and MEAI) pattern of having AddKeyedSqliteVectorStore alongside AddSqliteVectorStore (which doesn't accept a service key).
• Add methods should have an optional parameter to allow the user to determine the service lifetime.
• In some cases, the Add methods resolve a service from DI (SearchIndexClient, AzureAISearchVectorStoreOptions); in some cases it seems that we register the vector store as transient because of this (SearchIndexClient, we don't know what lifetime the dependency has), in others we don't (AzureAISearchVectorStoreOptions).
  • We may want to reexamine the idea of looking AzureAISearchVectorStoreOptions up in DI - I'm not sure why a user would want to do that, rather than simply passing it as a parameter. Possibly same with SearchIndexClient.
  • In general having AddXX methods with the same name that register the same thing (IVectorStore) with different lifetimes seems problematic.
• On that note, we sometimes register as Transient really heavyweight types like CosmosClient, which are very explicitly meant to be singletons. This seems like quite a perf pit of failure.
• IVectorizableTextSearch isn't actually registered, despite documentation.
• All extension methods are currently in the Microsoft.SemanticKernel namespace - this needs to change to Microsoft.Extensions.VectorData.
• Consider also registering the concrete types (e.g. AzureAISearchVectorStore) and not just the interfaces (IVectorStore) - that's important in case users want to access database-specific APIs etc.

[markwallace-microsoft]

@roji if you want someone on the core team to take this please let me know

[roji]

Thanks @markwallace-microsoft, I'll probably handle this.