Feature Request: `meta` property should allow nested data

[joneubank]

The meta property of dictionaries, schemas, and fields are currently restricted to being a flat key-property object. We have since found relevant use cases where we would like to be able to have nested data structures. We want to change the Lectern meta-schema to allow all meta properties to allow nested objects.

Example Use Case

The following is a proposed partial field definition for a date_of_birth field in a proposed schema. There is a desire to indicate how this field maps to other ontologies or data structures. This is done with a meta property named mappings

In the current system, a complicated string with different delimiters is provided. It is fine for human reading but can't easily be used programatically without string parsing.

{
    "name": "date_of_birth",
    "description": "Indicate participant's date of birth.",
    "valueType": "string",
    "meta": {
        "displayName": "Date Of Birth",
        "mappings": "All4One: Month,year of birth;mCODE STU3: Patient.birthDate;Phenopacket: Individual.date_of_birth;Beacon V2: Individual.date_of_birth",
        "source": "MOH"
    }
}

When meta fields are allowed to be nested we could instead represent this data as follows:

{
      "name": "date_of_birth",
      "description": "Indicate participant's date of birth.",
      "valueType": "string",
      "meta": {
        "displayName": "Date Of Birth",
        "mappings": {
          "All4One": "Month,year of birth",
          "mCODE STU3": "Patient.birthDate",
          "Beacon V2": "Individual.date_of_birth"
        },
        "source": "MOH"
      }
}

Detailed Description

• [ ] Update meta value type validations that are used in all levels of the Lectern meta schema (Dictionary, Schema, Field)
• [ ] Allow properties inside a meta value object to be a meta object.
  • This is recursive, so meta values have an unrestricted amount of nesting to work with

[joneubank]

@edsu7 Can you review the example I used to justify this change? I took it from the example you wrote in the comment on the conditional restrictions draft PR. The updated version is how I imagine you would prefer to capture this data.