re-introduce any_of when it is fully supported by Python serialization

In schema v5.0.0 we define the range of the slot contributor as:

any_of:
  - range: Person
  - range: Organization

However, after creating the Python classes with gen-python this is not handled correctly, ending up as using string (the default_range) as the range for the contributor property in Python. This results in the following unwanted RDF in the KH (example):

"schema:contributor": [
      "Person(id=rdflib.term.BNode('Na4a61fcb0b1f4eee9985cc4e0d841002'), name=['John Doe'], additionalType=[], description=[], url=[], altLabel=[], sameAs=[], sourceSystem=None, sourceSystemID=None, affiliation=[Organization(id=rdflib.term.BNode('N29b6197c4e7848219cdeedb0a883d5aa'), name=['Netherlands eScience Center'], countryName=[], hasGeometry=[], hasLocality=[], hasLogo=None, hasNFDI4EarthContactPerson=None, hasRorId=None, homepage=[], locality=[], politicalGeocodingURI=[], subOrganizationOf=[], altLabel=[], sameAs=[], sourceSystem=None, sourceSystemID=None)], email=rdflib.term.Literal('johndoe@esciencecenter.nl'), orcidId=rdflib.term.Literal('0000-0002-7508-000X'))",
      "http://localhost:8080/api/objects/n4ekh/1eeabd82e6d0ee32d19f",
      "http://localhost:8080/api/objects/n4ekh/d9537fb08d5db0e58768"
    ]

instead of what we would want:

"schema:contributor": [
      {
        "@type": "schema:Person",
        "schema:affiliation": {
          "@type": "foaf:Organization",
          "foaf:name": [
            "Netherlands eScience Center"
          ]
        },
        "schema:email": "johndoe@esciencecenter.nl",
        "schema:name": [
          "John Doe"
        ],
        "m4i:orcidId": {
          "@type": "xsd:anyURI",
          "@value": "0000-0002-7508-000X"
        }
      },
      {
        "@id": "n4ekh/1eeabd82e6d0ee32d19f"
      },
      {
        "@id": "n4ekh/d9537fb08d5db0e58768"
      }
]

This is an issue with the LinkML, probably already acknowledged by the maintainers, see https://github.com/linkml/linkml/issues/1483 where cmungall states that "pythongen doesn't fully support any_of yet.". Probably related issues to this are:

We need a temporary workaround for this, and re-introduce any_of later when it correctly handled by the python-gen command.