export qualifier annotations on the various starter-specific integrations

I think we should care about three different levels of support when it comes to integrating Spring Ai in projects with the starters and the level of automation.

here are the 3 tranches of support I think we have

1. user adds one starter (say OpenAI, or Bedrock, or Ollama, or whatever): everything works, no changes from the user. this is already present.

2. user adds two different starters (e.g.: Ollama and OpenAI): everything works, except user needs to discriminate the EmbeddingModels and ChatModels and the like. This might happen if they add a starter for a VectorStore which will expect only one ChatModel. This is easy enough: Spring supports discriminating between two implementations of the same type with qualifier annotations. To make things cleaner, and to be more in line with the rest of Spring(*) wherever auto configuration exports beans of the same type, I propose surfacing qualifier annotations to make this relatively common thing easier. So, each starter might have a qualifier. eg: @Ollama, @OpenAi, @Gemini, @Bedrock, etc. Users would not need to know or use or care about these qualifiers if they only have one starter on the class-path. they can just do

class Consumer { 

 Consumer (ChatModel cm){ .. } 
}

3. user has the same model but wants to authenticate/parameterize the model each time. In this case, the user will just straight up have to create their own beans. this is the least well supported at the moment. If you want two different OllamaChatModels, pointing to different models, for example, then you'll need to redefine the beans outright. we do a good job annotating our beans with @ConditionalOnMissingBean, but would be good to make sure its done consistently, so that if a user creates more than one instance of the same ChatModel, we should back off.

so: please add qualifiers to the various implementations of well known interfaces like ChatModel and EmbeddingModel. Thank you.

• here are some of the qualifier annotations in Spring Boot and Spring Cloud, two projects that have auto configuration that export bean definitions: @LoadBalanced, @BatchDataSource, @BatchTaskExecutor, @BatchTransactionManager, @QuartzDataSource, @QuartzTransactionManager, @LiquibaseDataSource, @FlywayDataSource, @EndpointConverter

Start by inventorying the starter-specific integrations and auto-configurations that provide ChatModel and EmbeddingModel beans. Read the existing ConditionalOnMissingBean usage and compare it with the Spring qualifier examples cited in the issue. Done means the relevant implementations expose consistent qualifiers and same-model custom beans are backed off consistently, with coverage for the affected integrations.