Scope out the work for reloadable unitdefs

Map out what are the current blockers for having a reliable unitdefs reloading mechanism as part of the gamedev workflow.

Study what is broken and how when you `/cheat` `/editdefs` and write on the `UnitDefs` table. Check if this is just a matter of caches in `LuaRules` and `LuaUI` and whether reloading those is enough to make it workable, or not.

Consider the possibility of having an artificial callin and callout (purely gameside), e.g. `EditUnitDef(unitDef{Id,Name}, attribute, value)`, that callout should write the UnitDef and invoke an artificial callin e.g. `UnitDefChanged(unitDef{Id,Name})`. Widgets and gadgets then change internal cache to leverage it.

### Proposal: have a gadget in basecontent/examples for editing unitdefs in real time

Should issue `/cheat` and `/editdefs` when triggered, detect if already cheat and editdef to avoid duplicate issuing.

Trigger should be something like `/editdef armpwn health 777`, this should send an unsynced message to the gadget, which should relay to the synced part of the gadget, which performs `UnitDefs["armpw"]["health"] = 777`, perform some sanitization to ensure the command is valid.

Reproduce the `/cheat` and `/editdefs` workflow, then trace writes to the `UnitDefs` table through `LuaRules` and `LuaUI`. Review the proposed gadget in `basecontent/examples` and determine whether cache reloads suffice or whether an artificial callin and callout are needed. Done means the current blockers and a workable reload or editing design are documented.

Written by the indexing model from the issue text.