fix(embedder)!: Use FQCN for embedder model config, to allow any Model child class

[welcoMattic]

Ref: #98

Before:

llm_chain:
    embedder:
        default:
            platform: 'llm_chain.platform.mistral'
            model:
                name: 'Embeddings'
                version: 'mistral-embed'

After

llm_chain:
    embedder:
        default:
            platform: 'llm_chain.platform.mistral'
            model:
                name: 'PhpLlm\LlmChain\Platform\Bridge\Mistral\Embeddings'
                version: 'mistral-embed'

This way, any class extending PhpLlm\LlmChain\Platform\Model can be used as embedder model, even one written by users themselves. This way, embeddings model of providers (OpenAI, Mistral, ...) can have the same class name.

[welcoMattic]

I didn't handle the BC here, let me know it this solution is ok. Then, I will add a BC layer to not break user's apps.

[OskarStark]

It is ok to break BC, we don't take BC promise serious until now as we are anyway using 0.x versions

[welcoMattic]

Same behaviour could be applied to chain config: https://github.com/php-llm/llm-chain-bundle/blob/main/src/DependencyInjection/LlmChainExtension.php#L250

WDYT @OskarStark @chr-hertel?

[chr-hertel]

Yup, that first implementation was def too stupid, true. And I guess the className thing is something that should be supported - especially when you thin about user land model classes for example.

However, looking at this config:

llm_chain:
    embedder:
        default:
            platform: 'llm_chain.platform.mistral'
            model:
                name: 'PhpLlm\LlmChain\Platform\Bridge\Mistral\Embeddings'
                version: 'mistral-embed'

This is a bit redundant, right? the service llm_chain.platform.mistral would anyways only support one embeddings class - I think we could also solve that by the Platform exposing which models (and their names) it would support. so that we would basically only chose from a subset of those classes.

WDYT?