[WIP] Provider base and implementation

[felixarntz]

Work in progress. This is a non-functional draft. It partly depends on the interfaces from #35, but also on more interfaces that don't exist yet.

At this point, the primary purpose is to clarify and showcase the vision for the eventual implementation of provider and model infrastructure, especially around the base classes that will bundle common logic without forcing any of it upon all providers (the only "forced" piece will be the interfaces).

As the actual interfaces become available, this PR will evolve with time to rely on them, eventually becoming functional and a proper implementation of the necessary infrastructure, as part of the tasks in #20.

The goal is to provide basic implementations for text and image generation for Anthropic, Google, and OpenAI, all based on their respective OpenAI API compatible REST API endpoints. While Anthropic and Google provide their alternative API specifications that they generally recommend, focusing on their OpenAI API compatible endpoints first is a more pragmatic approach that will get us up to speed more quickly. We can reconsider using their recommended APIs later, if there is any additional value from doing that.

For documentation on the relevant OpenAI API specifications for the endpoints this implements support for, see:

• https://platform.openai.com/docs/api-reference/models/list
• https://platform.openai.com/docs/api-reference/chat/create

[felixarntz]

@JasonTheAdams I implemented this for an early reference. Don't try it, it doesn't work - for that reason, also ignore any of the PHPCS / PHPStan errors :)
But please feel free to review and leave early questions / feedback.

[felixarntz]

@JasonTheAdams Note: For now, I put all the abstract and base classes into AiClient\Providers. Some of them may be better suited under AiClient\Providers\Models, let's discuss that as we iterate here.

Part of me likes them being in one place as they're so closely related, which goes back to my earlier preference to not separate provider and model code into different namespaces. But I'm happy to stay aligned with our current approach, we just have to figure out how that would work best.

[felixarntz]

@JasonTheAdams Aside: d9b32fc shows how complex maintaining the list of models and their capabilities is. The current list here for the OpenAI provider is purely based on my own testing that I did for AI Services, so even that is probably slightly inaccurate or out of date. Realistically, there's just no way for us to always stay on top of all those nuances, especially not for all the different providers.

In any case, that's what's needed for now, until we hopefully find a way to source this from some more reliable external database of sorts.