MQL5: add timer-based command polling for live trading

[biohazardxxx]

Summary

• In live trading, OnTimer() (which drains the command queue) was only called from OnTick() during backtesting. Commands from the .NET client would queue up and never be processed until the next market tick, making the EA unresponsive on low-volume symbols or outside market hours.
• Added EventSetMillisecondTimer(100) in init() for live trading mode so commands are polled every 100ms regardless of tick activity.
• OnTimer() is now also called on every tick (supplements the timer for lowest latency when ticks are flowing).
• Added EventKillTimer() in deinit() for proper cleanup.

Test plan

• Compile MtApi5.mq5 with MetaEditor — verified 0 errors, 0 warnings
• Attach EA to a low-volume symbol, connect .NET client, and verify commands are processed promptly even without ticks
• Verify backtesting mode still works correctly (timer is not started, OnTick() still calls OnTimer())
• Verify high-volume symbols still work with normal latency (no duplicate command execution)

🤖 Generated with Claude Code

[tudstudent]

Fix is correct and addresses a real problem — we confirmed that without the timer, commands hang indefinitely on low-volume symbols outside market hours.

Note: MQL4 (mq4/MtApi.mq4) has the same issue — OnTimer() is only called from within the backtesting IsTesting() block. Our PR #297 includes this fix for both MT4 and MT5 along with additional bug fixes.

[biohazardxxx]

Pushed b512562: the polling interval is now configurable via a new CommandPollingIntervalMs input (default 100 ms, clamped to 10–1000). Lowering it bounds worst-case command latency when the connector's PostMessage nudge is missed. Recompiled ex5 included.

[biohazardxxx]

Measured side-effect of the polling timer, found while runtime-testing #311: with EventSetMillisecondTimer active, the connector's PostMessage(WM_TIMER) nudge no longer wakes the expert — every command then waits for the next timer tick. Sequential commands measured at exactly 100.0 ms/command on this branch's EA vs 0.6 ms/command on an upstream-based EA (no timer, nudge-driven) against the same connector DLL on the same terminal. Likely cause: once a real EventSetTimer is registered, MT5 filters posted WM_TIMER messages (timer-id mismatch). The new CommandPollingIntervalMs input mitigates (10 ms → ~10 ms/cmd worst case), and #310 (async pipelining) restores throughput (20 commands in one tick, measured x19.6). A cleaner long-term fix may be nudging via a chart custom event (EventChartCustom/CHARTEVENT_CUSTOM) instead of WM_TIMER so the nudge and the safety-net timer coexist.