drmemtrace skip should hide timestamp+cpuid ordinals for moved records

I am now realizing that while we have no ordinal for the synthetic
timestamps we add after a chunk boundary, if we just "move" an earlier
timestamp in a linear walk we're not hiding the ordinals and in fact we
present the wrong ordinals. Probably these should also have no ordinal.

This is the problem, with ordinals 208 and 209 not being the real ones:
```
$ bin64/drrun -t drcachesim -simulator_type view -infile ../src/clients/drcachesim/tests/drmemtrace.allasm_x86_64.trace.zip -skip_instrs 131 -sim_refs 6
Output format:
<--record#-> <--instr#->: <---tid--->
------------------------------------------------------------
208 131: 1263623
209 131: 1263623
210 131: 1263623
211 132: 1263623 ifetch 1 byte(s) @ 0x0000000000401039 c3 ret %rsp (%rsp)[8byte] -> %rsp
```

No skipping:
```
201 127: 1263623
202 127: 1263623
203 127: 1263623
204 127: 1263623
205 128: 1263623 ifetch 4 byte(s) @ 0x0000000000401028 48 83 eb 01 sub $0x0000000000000001 %rbx -> %rbx
206 129: 1263623 ifetch 4 byte(s) @ 0x000000000040102c 48 83 fb 00 cmp %rbx $0x0000000000000000
207 130: 1263623 ifetch 2 byte(s) @ 0x0000000000401030 75 d9 jnz $0x000000000040100b (taken)
208 131: 1263623 ifetch 5 byte(s) @ 0x0000000000401032 e8 02 00 00 00 call $0x0000000000401039 %rsp -> %rsp 0xfffffff8(%rsp)[8byte]
209 131: 1263623 write 8 byte(s) @ 0x00007ffec215cba8 by PC 0x0000000000401032
210 131: 1263623
211 132: 1263623 ifetch 1 byte(s) @ 0x0000000000401039 c3 ret %rsp (%rsp)[8byte] -> %rsp
```

Start with the drmemtrace skip path exercised by the shown drrun command and compare its skipped output with the no-skipping output. Trace how moved timestamps and timestamp+cpuid marker records receive ordinals; done means moved records no longer display misleading ordinals while genuine records retain theirs.

Written by the indexing model from the issue text.