Expose Area Mex controller API

[UnderarmCape]

Work done

This PR adds a small controller-safe API bridge to cmd_area_mex.lua:

This commit is necessary in order to have functioning Area Mex behavior when using my gamepad support mod (see below)
https://github.com/UnderarmCape/underarmcape-bar-controller-support-attempt-01/releases

WG.controllerAreaMex.issueArea(x, y, z, radius, opts)

This lets controller UI code issue Area Mex with explicit center/radius parameters while reusing BAR's existing Area Mex logic.

The change avoids duplicating Area Mex internals inside a controller widget. The controller UI can provide the selected area directly, and cmd_area_mex.lua still owns the actual Area Mex behavior: metal spot selection, extractor/build-option logic, command ordering, and WG.resource_spot_builder.ApplyPreviewCmds.

Behavior

• Mouse Area Mex behavior is unchanged.
• Existing CommandNotify handling for GameCMD.AREA_MEX remains intact.
• Existing Area Mex spot selection and build-order logic is reused.
• Existing WG.resource_spot_builder.ApplyPreviewCmds flow is preserved.
• The controller API supports direct numeric params and table-style params.
• The controller API is cleaned up on widget shutdown.

Setup

No special setup is required for normal mouse/keyboard testing.

Controller-side testing requires a controller UI/widget that calls:

WG.controllerAreaMex.issueArea(x, y, z, radius, opts)

Test steps

• Start a local/skirmish game with a constructor selected.
• Use normal mouse Area Mex and confirm it still places mex build orders correctly.
• Confirm there are no Lua errors.
• If testing with the controller widget, call/use controller Area Mex and confirm it issues mex build orders for the selected area.

Testing performed

• Mouse Area Mex was manually tested and confirmed unchanged.
• Controller Area Mex was tested through the controller support mod using this API.

Notes

This is intended as a small upstreamable Lua API bridge for controller support. It does not add controller UI to BAR by itself; it only exposes a safe way for controller UI code to reuse the existing Area Mex implementation.

[WatchTheFort]

Can't area commands already be issued from Lua? Why is this needed? Is the issue that Area Mex is not actually implemented as an area command?

[sprunk]

I think this would be better solved by exposing this "give notifying order" utility

Beyond-All-Reason/luaui/Widgets/cmd_customformations2.lua

Line 370 in 8942707

local function GiveNotifyingOrder(cmdID, cmdParams, cmdOpts)