[AArch64] Split OP_prfm opcode, or provide named constants for the sub-opcode immediate operand

[derekbruening]

See the discussion at #4386 (comment) regarding opcode philosophy of separate opcodes for separate semantics.

This issue covers either splitting the OP_prfm opcode into OP_prfm_read_l1, OP_prfm_read_l1_nt, etc., with a helper to determine whether an opcode is a PRFM, or leaving the single OP_prfm and providing a named enum where DR_PRFM_READ_L1_NT, etc. are set to equal their encoded 5-bit immediate value in the source operand. Both approaches avoid the bit decoding currently at https://github.com/DynamoRIO/dynamorio/blob/master/clients/drcachesim/tracer/instru.cpp#L82 and we'd want to update that code with the result. We have pros and cons of both approaches; splitting the opcodes is a compatibilty break as well. Whoever takes on the work gets to pick the approach I suppose.

[derekbruening]

It's sounding like we have more votes for the single OP_prfm here: so we're considering the DC cache management types to be semantically different enough for separate opcodes, but not the prefetch types (nor the various SIMD operation variations we don't split inside the same opcode).

[derekbruening]

Xref #4393 which is a pre-req for opcode splitting.