Enhance the `draft info` output

Comienza con el comando draft info y compara su salida JSON actual con la estructura propuesta, similar a Azure Portal. Se considera terminado cuando se expongan los nombres para mostrar de las versiones, las versiones de las imágenes y del builder, los puertos predeterminados y una selección más amplia de versiones para los idiomas compatibles.

Is your feature request related to a problem? Please describe.

It would be really nice if the info command could provide enough information to build an experience like that of the Azure Portal:

In the above, selection of a language version allows consumers to infer both runtime and builder images, as well as a default port.

Mention what platform you want to support the new feature

All

Describe the solution you'd like

Currently, Draft outputs this (to take Java as an example):

    {
      "name": "java",
      "displayName": "Java",
      "variableExampleValues": {
        "BUILDERVERSION": [
          "3-jdk-11"
        ],
        "VERSION": [
          "8-jre",
          "11-jre",
          "17-jre",
          "19-jre"
        ]
      }

But an Azure Portal-like experience would require something like this:

{
    "name": "java",
    "displayName": "Java",
    "defaultPort": 8080,
    "versions": [
        {
            "name": "Java 8",
            "imageVersion": "8-jre",
            "builderVersion": "3-eclipse-temurin-8"
        },
        {
            "name": "Java 11",
            "imageVersion": "11-jre",
            "builderVersion": "3-eclipse-temurin-11"
        },
        {
            "name": "Java 17",
            "imageVersion": "17-jre",
            "builderVersion": "3-eclipse-temurin-17"
        },
        {
            "name": "Java 19",
            "imageVersion": "19-jre",
            "builderVersion": "3-eclipse-temurin-19"
        },
    ]
}

I.e. in addition to the current output, it would also allow consumers to extract:

• A display name for each of the versions
• An image version for each of the versions
• A builder version for each of the versions (if required in the Dockerfile)
• A default port for the language
• A more comprehensive selection of versions (e.g. for go, the info command outputs 1.16..1.19, yet the Portal displays 1.15..1.20)

Describe alternatives you've considered

As a consumer of Draft, I can maintain my own JSON mapping of languages to versions and ports, just as the Portal has to.

Additional context

I understand that maintaining a list of available versions (and associated images for each) is a maintenance overhead, but if Draft doesn't do that then consuming tools all have to, meaning it's hard to keep them in sync.