Potential Decoding Failure for instructions prefixed with 0x66

FEX fails to decode certain instructions when they are prefixed with `0x66`.

For the affaceted instructions, the `0x66` prefix is not required and does not change their behavior. Real hardware seems to simply ignore the prefix and execute the instruction normally. However, FEX fails in the `Frontend` decoding phase.

This happens, e.g, because the lookup tables (like `H0F38TableOps`) do not have an entry for the prefixed version.

The following non-exhaustive list fails to decode with a `0x66` prefix:
- `movnti`
- `adox`
- `sha1msg1`

In contrast, instructions like `cvttss2si` and `movd` get decoded fine when prefixed with `0x66`.

Related issues: #5667 and #5670.

Start in the Frontend decoding phase and inspect lookup tables such as H0F38TableOps, comparing prefixed and unprefixed entries. Reproduce the failure with the listed movnti, adox, and sha1msg1 instructions, then verify that a 0x66 prefix decodes them while preserving the behavior seen for unprefixed instructions.

Written by the indexing model from the issue text.