Add Gemini integration

[rlouf]

This PR provides a thin wrapper around the Gemini client. Gemini provides structured generation by accepting the following to define output types:

• A pydantic BaseModel. The output type is assumed to be JSON.
• A TypedDict. The output type is assumed to be JSON.
• A List type with a BaseModel or TypedDict argument. The output type is assumed to be a list of JSON objects.
• An Enum. The output type is assumed to be one of the fields in the enum.

This integration is already fairly complex:

1. We need to define a new Choice output type to handle the Enum output type;
2. The Gemini SDK does not accept JSON Schema string. Json thus needs to keep track of the original definition object. We should thus add a method to translate the definition object to JSON Schema instead of translating during initialization.
3. The Gemini SDK also accepts TypedDicts
4. The Gemini SDK accepts List type with arguments.

TODO

• Handle list and List more elegantly
• Use Json to infer the type of the definition object / reject invalid definition objects
• Add Json method to convert the definition object to JSON Schema
• Use Choice to infer the type of the definition object / reject invalid definition objects

Builds on #1240.

[rlouf]

We could let the Json object do type inference for the definition (and thus be the judge of what counts as a valid definition for a JSON object), and use a simple match statement here.

[torymur]

+1, a good indication of this is that this part stays the same:

            return {
                "response_mime_type": "application/json",
                "response_schema": output_type.original_definition,
            }

Keeping this translation clean of any other extra logic is desirable to clearly separate concerns.

[rlouf]

Having to handle List types here is not ideal.

[torymur]

This is interesting, seems that any model might have such custom types or even named similarly, but maybe defined a bit differently. We wouldn't want to limit these expressions too, but at the same time offer it only locally within this models?

[rlouf]

Do you mean define our own List type?

[torymur]

Yeah, maybe it might worth clearly defining such custom types separately for the model. And since they're specific to the model they won't be under common ones:
from outlines.types import Choice, Json

But instead from somewhere like:
from outlines.gemini.types import List?

Considering the variations of the models, it seems it might be quite common situation to manage the difference between them all. What do you think?

[rlouf]

I think that

from outlines.types import Choice, Json, List

would make sense as we want to support this type for open source models down the line as well.

We may want to support both list and typing.List down the line, but this is a quick and easy solution for now.

[torymur]

Yeah, extending the common when we are sure it's a good addition is ok, I wonder how to handle purely custom ones, which we wouldn't want to support for any other model but this particular one. For that we'd need some good examples, if List is out to be such custom example.