Fix issues and warnings caused by profiles.schema.json

[lhecker]

This addresses the following issues:

• The JSON Schema spec doesn't actually define whether objects with
  a "properties" key still require "type": "object" or not.
  VS Code for instance largely pretends as if it's implied, but when it
  encounters them inside a oneOf tree, then it behaves as if it isn't.
  In other words, we need to always set "type": "object".
• Declaring an oneOf containing a "type": "string" and an enum
  doesn't work, because if one of the enum cases is given, it results
  in both variants to match, since any enum is also a string.
  We have to use anyOf instead.
• SuggestionSource used "BuiltinSuggestionSource" inside a type
  key which doesn't work. We have to use $ref for that.

Closes #13387

Validation Steps Performed

• VS Code stops complaining ✅
• https://www.jsonschemavalidator.net/ ✅

[KalleOlaviNiemitalo]

IIUC, "properties" does not imply "type": "object"; if the instance is not an object, then "properties" in the schema has no effect. (The non-object instance always validates OK against "properties" because the instance cannot have any properties that would fail validation against the schemas in "properties".) https://json-schema.org/draft/2020-12/json-schema-core#section-10.3.2.1

When "properties" is used without "type" inside "oneOf",

{
    "oneOf": [
        {
            "type": "string"
        },
        {
            "properties": {
                "name": {
                    "type": "string"
                }
            }
        }
    ]
}

the string "hello" is valid instance for both subschemas for "oneOf", and thus invalid for the whole schema.

Does VS Code behave differently?

[lhecker]

If you use "properties" without "type", VS Code still offers the given properties up for auto-completion and it does use it for validation too. For instance this is part of our default config:

{
    "command":
    {
        "action": "splitPane",
        "split": "auto",
        "splitMode": "duplicate"
    },
    "keys": "alt+shift+d"
}

It does auto-complete the "splitMode" value to "duplicate". And if you fix the schema to say this:

"splitMode": {
    "default": "duplicate",
    "description": "...",
    "type": "string",         // added
    "enum": ["duplicate"]     // added
},

...then it even complains about "splitMode" being invalid if you use anything but "duplicate".
Even though we have defined that object without "type": "object".

[KalleOlaviNiemitalo]

If the schema does not have "type": "object", then the instance does not have to be an object. But if the instance is an object and the schema has "properties" with the same property names as in the instance, then the property values must match those schemas.

For the following schema, null, {}, and {"name": "smirk", "length": 5} are all valid. {"name": null}, 42, and [true] are not valid.

{
    "type": [ "null", "object" ],
    "properties": {
        "name": {
            "type": "string"
        }
    }
}

If you then remove "type": [ "null", "object" ] from the schema, 42, and [true] become valid. {"name": null} is still not valid.

In an editor, if you have already typed the opening brace, thus making the instance an object, then it seems sensible to auto-complete the names listed in '"properties"`.