chore: Enable AD_ChangeLog on WM_InOutBound tables

[EdwinBetanc0urt]

Enable ADempiere's native change log on the two outbound order tables (WM_InOutBound header and WM_InOutBoundLine lines) so that INSERT/UPDATE/DELETE operations are recorded per column with user, timestamp and old/new value. Diagnosing the recent duplicate outbound order incident (#1919) required reading application logs because no dictionary-level audit trail existed on these tables; this migration closes that gap and gives the ADempiere client a persistent, queryable history for future regressions.

Summary

• Toggle AD_Table.IsChangeLog = 'Y' on WM_InOutBound (AD_Table_ID = 53233) and WM_InOutBoundLine (AD_Table_ID = 53234) using a <PO Action="U"> step, so the rollback is implicit from the oldValue="false" attribute and no separate RollbackStatement is needed.
• Header-level audit (1 row per generation) is enough to detect the double-generation pattern reported in #1919 (two Created rows a few seconds apart on the same outbound order); line-level audit (N rows per generation) adds traceability against post-creation edits or SQL deletes on line quantities.
• AD_ChangeLog volume on the lines table scales with the number of selected order lines per generation; the migration's inline comment notes this so DBAs on high-throughput sites can plan a retention/purge policy before applying.

Changes

• xml/migration/1.5.13/00503670_D_1_5_13_Enable_ChangeLog_On_OutBound_Tables.xml — new migration, EntityType="D", SeqNo="503670", two <Step StepType="AD"> blocks updating AD_Table.IsChangeLog on the two records.

Test plan

• Apply the migration on dyd-dev and check SELECT IsChangeLog FROM AD_Table WHERE TableName IN ('WM_InOutBound','WM_InOutBoundLine') returns 'Y' for both.
• Generate an outbound order from the "Generar Orden de Salida" form and verify rows appear in AD_ChangeLog for both the header and each line (one row per audited column with IsAllowLogging = 'Y').
• Edit a saved outbound order line quantity from the ZK window and verify the change is logged with OldValue / NewValue.
• Rollback the migration (IsChangeLog back to 'N') and verify pre-existing AD_ChangeLog rows are preserved (only new events stop being written).
• Sample AD_ChangeLog growth in dyd-dev for one busy day to size a retention/purge policy before applying to production.