Add a Cube converter

Hi all 👋

I'd like to gauge interest in adding a converter between Ossie and **Cube** (cube.dev) under `converters/`.

[Cube](https://github.com/cube-js/cube) is a widely-used open-source semantic layer. Its data model is defined in YAML as `cubes` with `sql_table`/`sql` (source), `dimensions`, `measures`, and `joins` — conceptually very close to Ossie's `dataset` / `field` / `metric` / `relationship`:

| Cube concept | Ossie concept |
|---|---|
| `cube.name` | `dataset.name` |
| `cube.sql_table` / `cube.sql` | `dataset.source` |
| `cube.dimensions[]` | `dataset.fields[]` |
| `dimension.sql` | `field` expression |
| `dimension.type: time` | `field.dimension.is_time` |
| `cube.measures[]` | `metric` (dataset-scoped) |
| `measure.sql` + `measure.type` (sum/count/avg/...) | `metric.expression` + aggregation |
| `cube.joins[]` (`relationship: many_to_one` etc., `sql` join condition) | `relationship` (`from`/`to`/`from_columns`/`to_columns`) |
| `dimension.meta` / `measure.meta` | candidate home for round-trip metadata via `custom_extensions` |

I'd propose following the existing converter pattern (e.g. `converters/omni`, `converters/honeydew`):

1. A stable `vendor_name: CUBE` for `custom_extensions`.
2. Export (Ossie → Cube): one Cube YAML file (or one-file-per-cube layout) per Ossie dataset, with metrics attached as measures on their owning dataset and relationships translated to Cube `joins`.
3. Import (Cube → Ossie): parse a Cube schema directory into a single Ossie YAML, preserving anything Cube-specific (e.g. `pre_aggregations`, `data_source`, `public`/`shown` flags, `format`) in `CUBE` custom extensions so nothing is silently dropped.
4. Tests built off the TPC-DS example (`examples/tpcds_semantic_model.yaml`), including a round-trip test, following the `converters/omni` test layout.
5. A README documenting the mapping table and any unsupported constructs (Cube's `segments`, `pre_aggregations`, and Jinja-templated SQL are likely out of scope for v1 and would be called out as limitations, similar to how `converters/honeydew` documents its limitations).

Before I go further: **would a Cube converter be welcome in this repo?** Anything you'd want me to keep in mind on scope or approach — e.g. preferred package name (`apache-ossie-cube`?) or how you'd like multi-cube-per-file vs. one-file-per-cube handled on export?

Thanks!

Start by reading the existing converter patterns in converters/omni and converters/honeydew, then review examples/tpcds_semantic_model.yaml and their test layouts. A complete proposal would define the Cube-to-Ossie and Ossie-to-Cube mappings, round-trip coverage, and documented limitations in a converter README.

Written by the indexing model from the issue text.