APP CRASH: Regression from AArch64 decoder additions: FCSEL and FC*MP* not marked as reading/writing flags, resulting in mysterious crashes

PR #4966 added the FCSEL FCMP FCCMP FCCMPE opcodes, and PR #5012 added FCMPE. But they failed to update this code in codec.c:

         /* FIXME i#2626: When handled by decoder, add:
          * opc == OP_fcsel
          */
         eflags |= EFLAGS_READ_NZCV;

         /* FIXME i#2626: When handled by decoder, add:
          * opc == OP_fccmp || opc == OP_fccmpe || opc == OP_fcmp || opc == OP_fcmpe
          */
         eflags |= EFLAGS_WRITE_NZCV;

And since the opcodes are now decoded properly, the workaround from PR #4688 where OP_xx is marked as reading and writing the flags no longer applies. This leads to incorrect aflags behavior where these opcodes are not marked as reading or writing. Which leads to instrumentation corrupting application state in subtle ways, leading to strange application behavior and difficult-to-debug crashes.

We hit this on a large application. It took me several days to figure out the general area of the culprit and track it down to these opcodes. We've been down this road before, with difficult to debug problems coming from decoder bugs: that's what led to PR #4688's workaround. @AssadHashmi -- Are there further tests we could add? Further sanity checks to catch this type of regression ahead of time? It's not clear there's anything simple, unfortunately.

Should NZCV reading/writing be part of the codec entry instead of separate? That at least avoids two separate places that can get out of sync.