Feature: MDL surface for named pluggable-widget action slots beyond onClick/onChange (FileUploader createFileAction / onUploadSuccessFile)

[MohamedGamalEzzatAli]

Feature: MDL surface for named pluggable-widget action slots beyond onClick/onChange (e.g. FileUploader createFileAction / onUploadSuccessFile)

Summary

Pluggable-widget action properties are only authorable for two slots: onClick (mapped to the
widget's Action property) and onChange (mapped to OnChange). Every other named action
slot has no MDL surface — the generator's own comment states it:

// mdl/executor/widget_defs.go:318-322 @ v0.19.0
// Only the slots MDL can currently author (onClick → the widget's Action property,
// onChange → OnChange) are wired; other action slots have no MDL surface yet, so
// emitting a mapping for them would resolve to nothing.

The unmapped-property guard downstream correctly reports these as "would be dropped" instead
of writing nothing silently — the honest failure is appreciated; this issue asks for the
capability.

The concrete case that hits this

Mendix's FileUploader widget wires its behaviour through multiple named microflow-action
slots — e.g. createFileAction (which microflow creates the FileDocument) and
onUploadSuccessFile (post-upload handling) — each with its own argument binding. Today:

• the associatedFiles datasource IS authorable (works fine),
• but the action slots are not, so a FileUploader placed via MDL is a shell: every functional
  wiring step must be finished by hand in Studio Pro, per widget instance.

Any widget with more than one action property is in the same boat — the code comment at
widget_defs.go:536-540 names the Combobox's onChangeFilterInputEvent /
onChangeDatabaseEvent as further examples of action properties that must stay unmapped
under the current single-OnChange model.

Suggested shape (whatever fits the grammar's taste)

Named action-slot syntax on the widget property list, rather than positional inference —
something like:

FILEUPLOADER upl (
  AssociatedFiles: $Doc/Module.Files_Owner,
  Action createFileAction: CALL Module.ACT_CreateFile,
  Action onUploadSuccessFile: CALL Module.ACT_AfterUpload
)

The key requirements are: (1) address a slot by its property KEY (the widget XML already
declares them), (2) allow the microflow-call argument bindings the slot declares, and (3) keep
the existing honest behaviour — an unknown slot key should fail check, not drop.

Why it matters

Upload flows are among the most template-able parts of an app build (create-file microflow +
post-upload microflow follow the same pattern per entity), which makes them exactly what MDL
scripting is good at — and currently exactly the part that cannot be scripted end-to-end.

Environment: mxcli v0.19.0 (b313ff0); behaviour and comments verified at the tag.