Introduce annotations for JSON Schema explaining what object field contains object GTS ID

[Artifizer]

Currently, GTS implementations (for example, gts-rust) rely on simple heuristics to guess which object field contains the GTS identifier. This is effectively a temporary hack intended for cases where a JSON file needs to be opened, say in a IDE, and its object type inferred quickly.

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct GtsConfig {
    pub entity_id_fields: Vec<String>,
    pub schema_id_fields: Vec<String>,
}

impl Default for GtsConfig {
    fn default() -> Self {
        GtsConfig {
            entity_id_fields: vec![
                "$id".to_owned(),
                "gtsId".to_owned(),
                "gtsIid".to_owned(),
                "gtsOid".to_owned(),
                "gtsI".to_owned(),
                "gts_id".to_owned(),
                "gts_oid".to_owned(),
                "gts_iid".to_owned(),
                "id".to_owned(),
            ],
            schema_id_fields: vec![
                "$schema".to_owned(),
                "gtsTid".to_owned(),
                "gtsType".to_owned(),
                "gtsT".to_owned(),
                "gts_t".to_owned(),
                "gts_tid".to_owned(),
                "gts_type".to_owned(),
                "type".to_owned(),
                "schema".to_owned(),
            ],
        }
    }
}

This approach is inherently error-prone because:

1. A JSON document may define its identifier under a custom field name (for example, topic_id).
2. More critically, a field named id may exist for unrelated domain purposes, while the actual object identifier resides under a completely different key (e.g. object_id).

A more robust alternative would be to explicitly annotate the identifier field in the JSON Schema and then resolve a JSON instance by matching it against candidate schemas, rather than relying on field-name heuristics alone.

Action items:

• Update the spec and tests
• gts-rust fix
• gts-go fix
• gts-python fix
• gts-kit fix