Fix 68000 MOVE post increment destination pcode order

[EmirX3D]

This fixes a decompiler issue with 68000 move.* ..., (An)+ instructions where changing the destination pointer type could make the generated C look like a pre increment happened before the store. The underlying pcode was technically SSA correct, though the generic destination effective address handling ended up emitting the post increment before the write through the saved address. During type recovery, the decompiler could then merge the original and incremented pointer values together, leading to confusing output for typed byte pointers. To fix this, dedicated post increment destination operands were added for move.b, move.w, and move.l. These now emit the store first and only update the address register afterward, matching the expected instruction semantics more clearly in decompiled output. The special byte sized SP post increment behaviour is unchanged and still advances by 2

To validate, I compiled 68020.slaspec, 68030.slaspec, 68040.slaspec, and coldfire.slaspec
Related discussions/issues:

• mc68k: post-increment decompilation issues #9217

[EmirX3D]

(Please ignore the ddc41db commit. That is unrelated to this PR, instead it's related to #9204)

[fenugrec]

oh wow, interesting analysis. I had looked at the sleigh code looking for an obvious problem, but it makes sense that it would be a bit more subtle. Do you think other opcodes could be similarly affected ?

[EmirX3D]

oh wow, interesting analysis. I had looked at the sleigh code looking for an obvious problem, but it makes sense that it would be a bit more subtle. Do you think other opcodes could be similarly affected ?

@fenugrec Possibly. I haven't taken a look at them though, I was focused on your issue.