fix: populate global_symbols.relationships in expt-convert

[phuongddx]

Fixes the relationships half of #464: global_symbols.relationships is declared in the expt-convert schema but never written, so it is NULL for every row in every generated database.

Because the column exists and queries against it succeed, the omission is silently lossy — a consumer cannot distinguish "this symbol has no relationships" from "the converter never stored any." relationships is the only source for implementation and type-definition edges, so type-hierarchy features built on the SQLite output cannot work at all, and the failure is easy to misattribute to the language indexer that produced the .scip.

Change

insertGlobalSymbols() now serializes SymbolInformation.relationships into the existing column. The blob is framed exactly like chunks.occurrences in Chunk.toDBFormat — a zstd-compressed proto.Marshal of a wrapper message (SymbolInformation here, Document there) — so the encoding stays consistent within the file and remains self-describing.

Symbols with no relationships bind SQL NULL rather than a compressed empty message. That matters because insertGlobalSymbols is also called with synthetic &scip.SymbolInformation{Symbol: occ.Symbol} values for occurrence-only symbols; storing an empty frame for those would make "absent" and "present but empty" indistinguishable.

No schema change and no scip.proto change, so no regenerated bindings.

Testing

TestConvert_SmokeTest's fixture gains a symbol with an is_implementation relationship, and a checkRelationships helper joins the existing table of checks. It decompresses and unmarshals the stored blob, asserts a full round-trip of the relationship data, and asserts that symbols without relationships store NULL. The subtest fails on main ("map[]" should have 1 item(s), but has 0) and passes with this change; the other subtests are unaffected.

Verified end-to-end on a real scip-typescript index of a class implementing an interface:

BEFORE (v0.9.0):  5 symbols, 0 with relationships
AFTER  (patched): 5 symbols, 2 with relationships

The stored edges match the example in scip.proto's own Relationship documentation — Dog# → Animal# with is_implementation, and Dog#sound() → Animal#sound() with both is_implementation and is_reference.

I also decoded the blobs from an independent (non-Go) consumer that expects zstd(SymbolInformation) framing, and they read cleanly — which is some corroboration that this framing is what downstream readers of this schema already assume.

Not included: signature

#464 also notes that global_symbols.signature is never populated. I left it alone deliberately: the column is named signature, but SymbolInformation has no such field — the nearest is Signature signature_documentation = 7. Mapping one onto the other looks like a maintainer decision rather than something to guess at here. Happy to add it in a follow-up, or in this PR, given a preference.