feat: add serviceinfo URI

[AlpinDale]

In an effort to create a standard well-known URI for Inference servers, we, @db0 (AI Horde), @AlpinDale (Aphrodite Engine), and @LostRuins (KoboldCPP) have agreed on a set of key info to be broadcasted by every API server to identify itself. The spec contains other fields not included here, such as logo and version (for the software). As far as I know, tabby doesn't have an official logo, and since it's a rolling-release software, it doesn't have a version either. I thought about logging the commit here, but we don't have the infrastructure to log and store the commit hash yet. I can PR that in if needed.

Sample response:

{
  "version": 0.1,
  "software": {
    "name": "TabbyAPI",
    "repository": "https://github.com/theroyallab/tabbyAPI",
    "homepage": "https://github.com/theroyallab/tabbyAPI"
  },
  "api": {
    "openai": {
      "name": "OpenAI API",
      "base_url": "http://127.0.0.1:5000/v1",
      "documentation": "https://theroyallab.github.io/tabbyAPI",
      "version": 1
    },
    "koboldai": {
      "name": "KoboldAI API",
      "base_url": "http://127.0.0.1:5000/api",
      "documentation": "https://theroyallab.github.io/tabbyAPI",
      "version": 1
    }
  }
}

References:
PygmalionAI/aphrodite-engine#807
Haidra-Org/AI-Horde@eb5ec3d
LostRuins/koboldcpp@f153a14

https://github.com/Haidra-Org/AI-Horde/wiki/serviceinfo

[db0]

Would be good to ensure that a version alweys exists, even if, as you said it's only a commit hash

[henk717]

I don't think it will be a big deal if its a pseudo version number that gets bumped for major things.
Like for example if there is a critical inference bug tabby could bump it by 0.1 so we can identify the bad ones.
So if integrating proper versioning isn't feasible that would be a workaround.

[bdashore3]

The route should be in endpoints/core since those are propagated across all API servers.

[bdashore3]

This spec looks fine by me. Added comments on the commits themselves. Also to note, semver is a common way of releasing points of software, but it's not the only option.

Rolling release is used for applications in ecosystems that are always changing (such as the exl2/AI ecosystem at large). Since TabbyAPI isn't built, it makes sense to keep it in a rolling state. Embedding the commit sha makes the most sense here, but using a semver of 0.0.1 will work as well (like the docs).