feat: sltool dte decompile writes a mission as Luau source

[vdmkenny]

The second step of the text path in #1126: sltool dte decompile <mission> writes a mission as Luau source, and docs/formats/mission-source.md specifies the form.

• Records are global declarations named after their display names: ships and the markers, flight groups, squads, formations, curves, globals, parts with their code, and triggers with theirs. The script is Mission source: the script as statements, and back to the same bytes #1127's statements in Luau syntax.
• The game's values are written by the names the scripting API gives them, from the tables the game runs on: ship types, pilots, orders, conditions, head movements and the game's variables (source/vocabulary.zig). A value the game doesn't name, such as a mod's, stays a number. A trigger's function names its event's values after the condition catalogue's labels, such as hull_damage.
• The source leaves out what the game works out again, and parks what it never reads, such as editor data in the triggers and ships, as unknown and unused. New finding: the game reads nothing of the operand tables, sections 1, 22 and 26. mission_build_part_tables hands their entry to mission_fill_part, which pops it unread. It is documented in dte.md and annotated in Ghidra's names table, with mission_fill_part's third argument.
• The listing now asks the vocabulary which parameter takes an order, instead of matching SetAI's label itself.

All 44 shipped missions decompile. Building the text again, and the round trip to the same mission, come with sltool dte build, the next step.

It is about 1550 lines, half of them the specification and tests. The records, the script text and the names are only useful together.

Closes #1130