Add unsynced `wupget:FileChanged(path)`

### User stories

1) Develop a wupget, either in SDD folder or as a raw file. Engine doesn't notice changes, so every time you change a file you need to do something to reload it (call some `VFS.` function if it's a widget, call `/reloadceg` if it's a CEG, etc). Currently this can't be automated well because you need to poll all potential changed files (load file, compare, reload if different). You can make some assumptions (e.g. force a check on alt-tab) but that is fragile. See e.g. https://github.com/beyond-all-reason/Beyond-All-Reason/pull/3651

2) Have a crude widget that accepts live external input via some .txt file, because files are way more beginner friendly than sockets for multiple reasons. Same story here - you gotta poll the file for changes, you can miss a quick change if the rate is slow and will waste performance if the rate is high.

### Proposal

* add unsynced `wupget:FileChanged(path)` callin that runs when a file changes.
* by default, should monitor files within VFS, i.e. loaded SDDs and data folders (as defined by `SpringData` springsetting and/or the `--read-dir` cli param)
* contents of sdz/sd7 don't need to be handled
* optionally there could be `VFS.MonitorRawPathForChanges(path)` to start receiving updates for given `VFS.RAW` file outside data dirs.
* optionally any raw file outside data dirs that gets passed to other VFS interfaces could start being monitored as well.

Start by tracing the unsynced callin mechanism and the VFS interfaces involved in loaded SDDs, data folders, and raw paths. Review how SpringData and the --read-dir CLI parameter define monitored locations; done means FileChanged(path) reliably reports relevant external changes without handling sdz/sd7 contents, with any raw-path behavior clearly decided.

Written by the indexing model from the issue text.