Explain InfluxDB-to-QuestDB concept mapping, and merge sparse rows with a materialized view

[PasinduOshada]

Closes #149

The migration tutorial jumped straight to client code without saying what happens to the data model, and its fix for InfluxDB's sparse rows stopped at a one-off INSERT. This addresses both points from the issue.

Concept mapping

Adds a table mapping InfluxDB concepts to QuestDB ones — buckets, measurements, tags, fields, points, series, shards, retention policies and continuous queries — followed by the two consequences that actually change how a deployment is sized:

• tags are ordinary SYMBOL columns, not a separate kind of thing, so a value stored as a field in InfluxDB can be a SYMBOL here without redesigning the schema;
• there is no series object to track, so a high-cardinality tag costs storage in that column rather than multiplying into series the database must manage.

Sparse rows: materialized view + TTL

The existing section explained the problem and gave a max() query, then stopped at INSERT ... SELECT. Reworked per the issue to:

• collapse the rows continuously with a materialized view over SAMPLE BY 1s, with a note on why that interval is what merges the fragments (every ILP line split out of one reading shares a timestamp) and when to widen it;
• age out the raw ILP table with ALTER TABLE ... SET TTL, noting a view's retention is independent of its base table;
• a :::note that on Enterprise, table TTL is superseded by storage policies while materialized views continue to use TTL.

Notes

• Purely additive — 97 insertions, no deletions, no existing content reworded.
• Syntax checked against query/sql/create-mat-view.md, concepts/ttl.md and concepts/symbol.md rather than written from memory.
• All internal links used already resolve elsewhere in the repo, so the onBrokenLinks: "throw" build should pass.

Happy to adjust tone, table rows, or the SAMPLE BY interval if you'd rather it read differently.