Generate the OTIO Core Specification from code + curated overlay

[jhodges10]

Summary

This is a first step toward generating the OTIO Core Specification from the code rather than maintaining it by hand. It adds a generator that assembles a full specification document from two sources:

1. The code — every serializable schema object, its fields, field types, default values, inheritance, and the semantic docstrings carried by the bindings.
2. A curated markdown overlay — the human-authored narrative (intro, conventions, the metadata dictionary, root objects, JSON serialization) and the per-object integrator usage guidance that doesn't belong in terse API docstrings.

The per-object semantic definitions live in the binding docstrings (single source of truth, also improves IDE/readthedocs help); the narrative and usage guidance live in the overlay. The generator interleaves them.

What's here

• Enriches autogen_serialized_datamodel.py so the serialized-schema docs now carry per-field type info (derived from the pybind11 getter signatures, normalized to spec vocabulary — String, Double, Array[Effect], Map[String, MediaReference], TimeRange, …), optional flags, default values, and a class-level inheritance chain. (Resolves the long-standing # @TODO: having type information here would be awesome.)
• Adds autogen_core_specification.py, which reuses that model and stitches it together with a curated overlay to produce docs/spec/otio-core-specification.md. The overlay (docs/spec/core-specification-overlay.md) is plain markdown with HTML-comment directives (@preamble / @section / @object / @appendix), parsed with the stdlib — no new dependencies.
• Completeness contract: generation fails unless every non-plugin schema object is documented by exactly one @object entry. Adding a new schema to the code forces a matching overlay entry, so the spec can't silently drift.
• Fills in missing per-field semantic docstrings on the otio and opentime bindings (e.g. source_range, kind, global_start_time, available_range, target_url, RationalTime.value/rate, TimeRange.start_time/duration, name/metadata). These flow into both the serialized-schema docs and the specification.
• Tooling: make spec / make spec-update, plus a regenerate-and-compare unit test (CoreSpecificationTester) matching the existing autogen-doc pattern.

Regenerating

make spec-update         # regenerate docs/spec/otio-core-specification.md
make doc-model-update    # regenerate the serialized-schema docs

Edit prose in docs/spec/core-specification-overlay.md; edit field/object definitions in the bindings.

Testing

• CoreSpecificationTester, SerializedSchemaTester, and PluginDocumentationTester pass.
• Core functional tests (clip / marker / transition / timeline / opentime / color) pass — the binding changes are docstrings only.

Notes

• The binding docstring additions require a recompile before regenerating the docs, since the generator reads docstrings from the compiled module.
• Follow-ups worth considering: cardinality indicators (0..1 / 0..*), per-property "inherited from" grouping, intra-document cross-links between object headings, and UML/diagrams.