replace modelOverridesRecommendedSettings with selfHostedModels

[emidoots]

Previously, for providing self-hosted model' configuration (the models we've tested and believe work well), a site admin would use configuration like this:

"modelConfiguration": {
    ...
    "modelOverridesRecommendedSettings": [
      "mistral::v1::mixtral-8x7b-instruct",
      "bigcode::v1::starcoder2-7b"
    ],
}

A few problems with this:

1. If you are NOT self-hosting models, you probably really should not be using this option, as it would set serverSideConfig options specific to self-hosting, but it's naming "recommended settings" which kind of suggests otherwise!
2. When self-hosting models, there is almost a 1:1 correlation of provider to actual API endpoint (because you have a single endpoint per model) - so not being able to configure the mistral or bigcode parts of the modelref above is problematic (restricts you to hosting 'only one model per provider'). The only escape for this currently is to abandon the defaults we provide with modelOverridesRecommendedSettings and rewrite it using modelOverrides fully yourself.
3. When self-hosting models, needing to configure the serverSideConfig.openaicompatible.apiModel is a really common need - the most common option probably - but again there's no way to configure it here, only option is to abandon defaults and rewrite it yourself.
4. If we improve the default values - such as if we learn that a higher context window size for mixtral-8x7b-instruct is better - we currently don't have a good way to 'release a new version of the defaults' because the string is a model ref mistral::v1::mixtral-8x7b-instruct we'd have to do this by appending -v2 to the model name or something. Having versioning here is important because there are both:

• Breaking changes: if we increase the context window at all, site admins hosting these models may need to increase limits in their hosted model deployment - or else the API may just return a hard error ('you sent me too many tokens')
• Non-breaking changes: if we decrease the context window, Cody responses will get faster, and it's fine to do. Similarly, adding new stop sequences may be fine for example.

This PR fixes all of these^ issues by deprecating modelOverridesRecommendedSettings and introducing a new selfHostedModels field which looks like:

"modelConfiguration": {
    ...
    "selfHostedModels": [
      {
        "provider": "mistral",
        "model": "mixtral-8x7b-instruct@v1",
        "override": {
          "serverSideConfig": {
            "type": "openaicompatible",
            "apiModel": "mixtral-8x7b-instruct-custom!"
          }
        }
      },
      {
        "provider": "bigcode",
        "model": "starcoder2-7b@v1",
        "override": {
          "serverSideConfig": {
            "type": "openaicompatible",
            "apiModel": "starcoder2-7b-custom!"
          }
        }
      }
    ],
}

Notably:

• The provider part of the model ref is now configurable, enabling self-hosting more than one model per provider while still benefitting from our default model configurations.
• "model": "starcoder2-7b@v1", is no longer a model ref, but rather a 'default model configuration name' - and has a version associated with it.
• override allows overriding properties of the default "model": "starcoder2-7b@v1", configuration, like the serverSideConfig.apiModel.

Importance

I'm hoping to ship this to a few customers asap;

• Unblocks customer https://linear.app/sourcegraph/issue/PRIME-447
• Fixes https://linear.app/sourcegraph/issue/PRIME-454 (you can see some alternatives I considered here before settling on this approach.)

Test plan

Manually tested for now. Regression tests will come in the near future and are being tracked on Linear.

Changelog

Improved configuration functionality for Cody Enterprise with Self-hosted models.

[chrsmith]

Adding an approval to unblock you. But will need to take a closer look to internalize what you are saying later.

However, since the "preferred model" or "self-hosted models" aren't on the critical path for the LLM model selection or other sort of "standard" config code path, I'm not too worried about the breaking changes/regressing things here.