Support for anyOf, even network analysis shall support selector

[PhilipPartsch]

In Sphinx-Needs, we can define selector to define which needs are been covered by the schema.
For maintenance reasons it would be cool, if in a network analysis, these selector scripts can be used.
E.g. like in the example

Selector:

        "select_asreq": {
            "properties": {
                "type": {
                    "const": "asreq"
                }
            }
        },

"select_GROUP__requirements": {
      "anyOf": [
          {
              "$ref": "#/$defs/select_sysreq"
          },
          {
              "$ref": "#/$defs/select_swreq"
          },
          {
              "$ref": "#/$defs/select_asreq"
          }
      ]
  },

In the schema:

        {
            "id": "schema_TYPE__test_specification",
            "select": {
                "$ref": "#/$defs/select_test_specification"
            },
            "validate": {
                "local": {
                    "allOf": [
                        {
                            "$ref": "#/$defs/TYPE__test_specification"
                        }
                    ],
                    "unevaluatedProperties": false
                },
                "network": {
                    "verifies": {
                        "contains": {
                            "local": {
                                "$ref": "#/$defs/select_GROUP__requirements"
                            }
                        },
                        "minContains": 0
                    }
                }
            }
        },

[ubmarco]

While anyOf is certainly well supported for jsonschema, I decided to avoid it for sphinx-needs schemas.json validation.
The main reason is that it is very hard to generate good error messages. This makes debugging a nightmare.
Imaging each of the 3 anyOf schemas has some complexity, then if none of the 3 schemas are validating, you have to emit 3 different errors. All of them are required to understand why the whole selector or validator fails.
For now I am proposing to fan-out the selectors / validators to multiple rules.
You may also maintain a project specific meta-model format, in which you keep your simplified version, and then generate schemas.json from it. Each rule can also get a dedicated ID and message, which makes it easier to understand for end users.