Feature: Move (.move) language support

[rjvkn]

Right now a Move project indexes as nothing. .move isn't in EXTENSION_MAP, so isSourceFile skips every file and codegraph init finishes with 0 files indexed (no error, index_state: complete). Move is the Sui/Aptos smart-contract language and a pretty active source-review target, so it'd be great to have it alongside Solidity.

I've got a working extractor and would be happy to open the PR. Checking in first mainly about which grammar you'd want vendored.

The extractor follows solidity.ts closely. Move's wrinkle is that a module's members live under a module_body and struct/enum fields hang off struct_fields:/enum_variants: rather than a body: field, so (exactly like the Solidity extractor does for its bodyless struct/enum) I drive module/struct/enum from visitNode and let the generic dispatcher handle the rest:

• module_definition (and the ;-label form) → module, pushed as a scope so its functions/structs/constants nest under it
• function_definition (+ native/macro variants) → function, kept out of methodTypes so the module being class-like doesn't turn free functions into methods
• struct_definition → struct with its field_annotations as fields; enum_definition → enum with its variants
• constant → constant, use_declaration → import, call_expression/macro_call_expression → calls (intra-module helper(x) resolves by bare name through the generic path)

The change is the usual set: move.ts, the move entries in grammars.ts (EXTENSION_MAP/WASM_GRAMMAR_FILES/VENDORED_WASM_LANGS/display name), index.ts, types.ts, and the vendored tree-sitter-move.wasm.

The one thing I'd like your call on: the grammar. I built the wasm from embe221ed/tree-sitter-move-sui, which is a maintained superset of Mysten's canonical tzakian/tree-sitter-move and parses the 2024 Sui syntax (module a::b;, public struct, enum). But it's a single-author fork, and your vendored grammars look sha-matched to specific upstream tarballs, so you may prefer tzakian or the aptos-labs grammar. Happy to build against whichever you want to standardize on.

I've run it end to end (indexed a Sui 2024 package, got module/struct/function symbols and the intra-module call edge), so the extractor itself is proven, just want to land it on the grammar you'd actually maintain.