Need dasher_reset_training: in-memory training buffer resurrects files deleted by frontend Reset

[willwade]

Found during Dasher-GTK#84 review (loop 2); applies to every frontend's training Reset (Dasher-Windows#54 shipped, Dasher-Android#38 and Dasher-GTK#84 in flight).

The problem

Frontend Reset deletes training_*.txt from the user dir — but the engine still holds:

• strTrainfileBuffer — text typed since the last context switch, and
• the trained LM state in memory.

WriteTrainFileFull appends that buffer to the training path on every output-context change (AlphabetManager.cpp:672), alphabet change (DasherInterfaceBase.cpp:492), and — since #85 — context destruction (CAPI.cpp:946 destroy-flush).

So: type → Reset → quit and the destroy-flush recreates training_*.txt with the pre-reset session text; the next launch's startup scan reloads it. The Reset dialogs promise "returns to built-in defaults on next launch / cannot be undone", which is currently only partly true. Post-reset typing re-accumulating is arguably fine (it's new learning); the bug is the pre-reset buffer surviving the file deletion.

Proposed API

// Clear the pending adaptive-training buffer AND drop everything the
// current LM has learned from user text (rebuild to the bundled corpus
// state). Returns 0 on success, -1 on failure.
DASHER_API int dasher_reset_training(dasher_ctx* ctx);

Implementation sketch: clear strTrainfileBuffer/strTrainfileContext in the alphabet manager, then force the same LM-rebuild path an alphabet change takes (fresh NCManager/trainer over the data dir only). Bump DASHER_CAPI_VERSION to 2 so frontends can require it before promising a full reset in their dialogs.

Frontend interim

Until this ships, frontends soften their Reset copy to promise only file deletion + restart (Dasher-GTK#84 is adjusting its wording now).