x86: PUSHF/POPF address size fixes (64-bit mode)

[Sleigh-InSPECtor]

The addrsize should be ignored for PUSHF/POPF instructions. This was potentially used before the LONGMODE_ON context bit was introduced to distinguish the 64-bit behavior from the 32-bit behavior. Since addrsize can be manipulated using the address size override prefix, it can cause the wrong PUSHF/POPF size to be decoded. The LONGMODE_ON constraint is now sufficient, so this PR simply removes the unnecessary addrsize constraint.

e.g.,

• 67669c PUSHF with RSP=0x1002, ZF=1
  • Hardware Reference (AMD CPU & Intel CPU): { mem[0x1000] = 4201, RSP=0x1000 }
  • x86:LE:64:default (Existing): "PUSHFQ" { mem[0xffa] = 4000000000000000, RSP=0x0ffa }
  • x86:LE:64:default (This patch): "PUSHF" { mem[0x1000] = 4000, RSP=0x1000 }

(Note: on the hardware reference, extra bits that are set correspond to EFLAGS.res1 (bit 1) and EFLAGS.TF (bit 8))

• 67669d POPF with RSP=0x1000, mem[0x1000] = 4000
  • Hardware Reference (AMD CPU & Intel CPU): { ZF=1, RSP=0x1002 }
  • x86:LE:64:default (Existing): Invalid Instruction
  • x86:LE:64:default (This patch): "PUSHF" { ZF=1, RSP=0x1002 }

---

The LONGMODE_OFF constructors have been left alone in this PR, although they technically should also ignore address size overrides. With LONGMODE_OFF, the address size is used to determine whether the segment pcodeop is applied during address translation, however segmentation should still be applied in 32-bit protected mode, but since most users are likely to be working with 32-bit programs where segment bases are all zero, the current behavior probably behaves better than injecting segment ops everywhere.

(It could make sense to introduce pseudo registers like CS.base/DS.base/etc... that are assumed to be zero but are user overridable, like the way the direction flag is handled)