[drmemtrace] Bad prefetch address crashes raw2trace

Xref https://github.com/DynamoRIO/dynamorio/issues/7364 which relates to this issue when memory tagging is enabled.

drmemtrace raw trace entries (`offline_entry_t`) earmark the top 3 bits of the 64-bit memory access (`offline_entry_t.addr`) entries for the entry type: https://github.com/DynamoRIO/dynamorio/blob/d647968e1fcb1e1b57fef88cfcb7c6b74332e0a5/clients/drcachesim/common/trace_entry.h#L1167

The fewer bits for the address are sufficient in general, since the top bits of all memory accesses may be all zero (`OFFLINE_TYPE_MEMREF`[1]) or all 1 (`OFFLINE_TYPE_MEMREF_HIGH`[2]). But we've found certain cases where this does not hold, even outside the cases #7364 talks about.

Prefetch instructions may take the liberty to not use a valid memory address always, as they may not always fault, and it is simpler/efficient for them to not perform too many checks before issuing a prefetch. This means a prefetched memory address may have some of the top 3 bits set.

Such an `offline_entry_t` entry will look like some other `OFFLINE_TYPE_*` entry depending on the exact address. Some traces were observed to crash during raw2trace at https://github.com/DynamoRIO/dynamorio/blob/d647968e1fcb1e1b57fef88cfcb7c6b74332e0a5/clients/drcachesim/tracer/raw2trace.cpp#L456 with the "Unknown trace type " error.

Creating this issue as a subset of #7364, with the goal to add an immediate fix for such prefetch instructions. This is not a separate feature like the support for memory tagging in #7364, but a bug in today's claimed support.

[1]: https://github.com/DynamoRIO/dynamorio/blob/d647968e1fcb1e1b57fef88cfcb7c6b74332e0a5/clients/drcachesim/common/trace_entry.h#L931
[2]: https://github.com/DynamoRIO/dynamorio/blob/d647968e1fcb1e1b57fef88cfcb7c6b74332e0a5/clients/drcachesim/common/trace_entry.h#L940