Attempts to speed up the initial page loading by delaying loading the
expensive `/class/{class_id}/models` endpoint. The delay comes from the
fact that the endpoint calls on the OpenAI/AzureOpenAI `/models`
endpoint. In this new design, the endpoint isn’t called until it’s truly
needed, which is when the Create/Edit Assistant page is loaded. We
instantiate a new `modelsPromptsStore = writable<Record<number,
AssistantModels>>({})` store so we only call the
`/class/{class_id}/models` endpoint once per class per session.

The `/class/{class_id}` and `/class/{class_id}/thread/{thread_id}` pages
used the `supports_vision` and `vision_support_override` parameters from
the `AssistantModel` object. To resolve this dependency without calling
on the `/class/{class_id}/models` endpoint, we make the following
changes:
- a new `/models` endpoint (note it’s not class-dependent) returns all
PingPong-supported models with the following properties:
`supports_vision` and `azure_supports_vision`.
- for now, `azure_supports_vision` is always False, which mimics the old
`vision_support_override` behavior of `/class/{class_id}/models` when
the OAI client was `AsyncAzureOpenAI`.
- the Class object has a new `ai_provider: AIProvider | None = None`
property
- the client uses the `class_.ai_provider` property to determine if it
should use `azure_supports_vision` for `visionSupportOverride`.