feat: add ContractInterface for more flexible normalizer configuration

[DZunke]

Could fix part of #371 - the question for flexibility.

Why? Messages are given on platform calls and are given with the MessageInterface. So it is very flexible what could be given on call. Normalizers are only configured once, internally. So one side is highly flexible, the other side not.

Giving the contract an interface allows creating own contracts with whatever backed technology one wants. So more flexible. Additionally it allows to add a contract that has an amount of normalizers one wants. For making it easier i thought about having model contract sets. I did it for anthropic, google and the platform itself.

So a custom contract could look like

use PhpLlm\LlmChain\Platform\Bridge\OpenAI\PlatformFactory;
use PhpLlm\LlmChain\Platform\Contract;

$platform = PlatformFactory::create(
    'my-api-key',
    contract: Contract::create(new MyOwnMessageBagNormalizer(), new MyOwnMessageThingyNormalizer()),
);

or, totally flexible:

use PhpLlm\LlmChain\Platform\Bridge\OpenAI\PlatformFactory;

$platform = PlatformFactory::create(
    'my-api-key',
    contract: new MyVeryOwnContractUtilizingJsonStreamer(),
);

Maybe this could be a way for more flexibility with the combination of non configurable normalizer and "unknown" message input?

[OskarStark]

do we need the alias?

[DZunke]

Not really. Removed it.

[OskarStark]

Suggested change

	final readonly class AnthropicSet
	final readonly class AnthropicDefaultContract

Suggested change

	final readonly class AnthropicSet
	final readonly class AnthropicContract

?

[OskarStark]

Ah it is not a contract yet, hmm 🤔

[DZunke]

No. I have seen that there are Contract Builds that combine mixed model contract normalizers so my thought here was to give them as a "set" like rector is doing it for some tools. So you could combine the set. Maybe this is too much? 🤔

[OskarStark]

🤔

[chr-hertel]

Looks great at the first glance - need to give it a proper read later - thanks already @DZunke!