Provider base and implementation for Anthropic, Google, and OpenAI via common abstractions

[felixarntz]

This PR provides basic implementations for text 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

The approach is as follows:

• Implement abstract classes for API based providers.
• Implement abstract classes for OpenAI API compatible providers (extending the respective classes for API based providers).
• Implement Anthropic, Google, and OpenAI providers based on these classes.
  • Due to the abstraction, their implementations are quite simple. The only heavy lifting is about the model metadata, which (at least for now) needs to be hand-maintained for the most part, since their APIs barely provide any details about what each model supports. See Abstracting away the need to manually maintain tons of provider and model metadata #4 for a potential long-term solution to simplify that.
  • It's worth noting that at least this is only important for model discovery. If the developer knows which model to use, the part about what each model supports doesn't matter, as it's not validated inside the model implementations in any way. The API itself would already validate and error as needed, and due to the complexity as well as allowing to always use the latest API capabilities, implementing this in our own code is not worth the tradeoff.
• Hook up central interface implementations for HttpTransporter and RequestAuthentication to the provider classes, orchestrated via ProviderRegistry. This ensures under the hood that every relevant provider class has the necessary implementations set, without the provider class implementation itself having to worry about that.

A subsequent PR will be opened to implement image generation for Google and OpenAI (Anthropic doesn't support that).

[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.

[JasonTheAdams]

Finished going through all the code! Tons of great work! Excited to wrap this up!

[dkotter]

This all looks really good to me. Left a few comments though feel free to ignore those if they're not valid. Was giving this a look to see how we would implement this in ClassifAI

[JasonTheAdams]

I love it! LGTM!! 🎉