x64 common.floatpc_xl8all fails non-deterministically with a truncated pc

Splitting from #2145 as it does not look like this is easily solved.

I can repro the common.floatpc_xl8all failure seen on Appveyor on my local
win10 and win8.1 VM's every so often: a few times every 1000 iters.

```
% for ((i=0; i<1000; i++)); do echo $i; bin64/drrun -translate_fpu_pc -- suite/tests/bin/common.floatpc.exe; done 2>&1 | tee OUT
```
2 instances

At -loglevel 2, 1 instance out of 1000:

```
688

FXSAVE64 intra is correctly handled
FXSAVE64 inter is **incorrectly** handled
FXSAVE intra is correctly handled
FXSAVE inter is correctly handled

```

Comparing success and failure log files relevant lines:

Success:
```
Entry into F3218(0x00007ff6e956118b).0x00007ff6697d15c8 (shared)
Exit from F3218(0x00007ff6e956118b).0x00007ff6697d15e8 (shared) [common.floatpc.exe]

Entry into F3219(0x00007ff6e95611a4).0x00007ff6697d15f8 (shared)
Exit from F3219(0x00007ff6e95611a4).0x00007ff6697d163c (shared) [common.floatpc.exe]
(target 0x00007ff6e95611b7 not in cache)
float_pc_update: fp state 0x000000719070fbb0
recreate_app_pc -- translating from pc=0x00007ff6697d15d8
recreate_app : pc is in F3218(0x00007ff6e956118b)
ilist for recreation:
TAG 0x00007ff6e956118b
+0 L3 48 8b c1 mov %rcx -> %rax
+3 m4 @0x00007ff669682288 48 ba 98 11 56 e9 f6 mov $0x00007ff6e9561198 -> %rdx
7f 00 00
+13 L3 48 89 10 mov %rdx -> (%rax)[8byte]
+16 L3 d9 ee fldz $0.000000 -> %st0
+18 L3 b8 01 00 00 00 mov $0x00000001 -> %eax
+23 L3 83 f8 01 cmp %eax $0x00000001
+26 L4 @0x00007ff669686640 0f 85 a9 2e ee 7f jnz $0x00007ff6e95611bf
+32 L4 @0x00007ff669683a88 e9 8f 2e ee 7f jmp $0x00007ff6e95611a4
END 0x00007ff6e956118b

recreate_app -- found valid state pc 0x00007ff6e9561198
recreate_app -- found ok pc 0x00007ff6e9561198
recreate_app_pc -- translation is 0x00007ff6e9561198
float_pc_update: translated 0x00007ff6697d15d8 to 0x00007ff6e9561198

dispatch: target = 0x00007ff6e95611b7

<...>

Entry into F3260(0x00007ff6e9561202).0x00007ff6697d1838 (shared)
Exit from F3260(0x00007ff6e9561202).0x00007ff6697d187b (shared) [common.floatpc.exe]
(target 0x00007ff6e9561214 not in cache)
float_pc_update: fp state 0x000000719070fbb0
float_pc_update: speculating: pc 0x00000000697d1818 + top half of vmcode = 0x00007ff6697d1818
recreate_app_pc -- translating from pc=0x00007ff6697d1818
recreate_app : pc is in F3259(0x00007ff6e95611e9)
ilist for recreation:
TAG 0x00007ff6e95611e9
+0 L3 48 8b c1 mov %rcx -> %rax
+3 m4 @0x00007ff669683de8 48 ba f6 11 56 e9 f6 mov $0x00007ff6e95611f6 -> %rdx
7f 00 00
+13 L3 48 89 10 mov %rdx -> (%rax)[8byte]
+16 L3 d9 ee fldz $0.000000 -> %st0
+18 L3 b8 01 00 00 00 mov $0x00000001 -> %eax
+23 L3 83 f8 01 cmp %eax $0x00000001
+26 L4 @0x00007ff669685a40 0f 85 05 2f ee 7f jnz $0x00007ff6e956121b
+32 L4 @0x00007ff669685458 e9 ed 2e ee 7f jmp $0x00007ff6e9561202
END 0x00007ff6e95611e9

recreate_app -- found valid state pc 0x00007ff6e95611f6
recreate_app -- found ok pc 0x00007ff6e95611f6
recreate_app_pc -- translation is 0x00007ff6e95611f6
float_pc_update: translated 0x00007ff6697d1818 to 0x00007ff6e95611f6

dispatch: target = 0x00007ff6e9561214
```

Failure:
```
Entry into F3218(0x00007ff6e956118b).0x00007ff6697d15c8 (shared)
Exit from F3218(0x00007ff6e956118b).0x00007ff6697d15e8 (shared) [common.floatpc.exe]

Entry into F3219(0x00007ff6e95611a4).0x00007ff6697d15f8 (shared)
Exit from F3219(0x00007ff6e95611a4).0x00007ff6697d163c (shared) [common.floatpc.exe]
(target 0x00007ff6e95611b7 not in cache)
float_pc_update: fp state 0x0000003ea0b7f8d0
float_pc_update: pc 0x00000000697d15d8 is translated already

dispatch: target = 0x00007ff6e95611b7

<...>

Entry into F3259(0x00007ff6e9561202).0x00007ff6697d181c (shared)
Exit from F3259(0x00007ff6e9561202).0x00007ff6697d185f (shared) [common.floatpc.exe]
(target 0x00007ff6e9561214 not in cache)
float_pc_update: fp state 0x0000003ea0b7f8d0
float_pc_update: speculating: pc 0x00000000697d17fc + top half of vmcode = 0x00007ff6697d17fc
recreate_app_pc -- translating from pc=0x00007ff6697d17fc
recreate_app : pc is in F3258(0x00007ff6e95611e9)
ilist for recreation:
TAG 0x00007ff6e95611e9
+0 L3 48 8b c1 mov %rcx -> %rax
+3 m4 @0x00007ff669683de8 48 ba f6 11 56 e9 f6 mov $0x00007ff6e95611f6 -> %rdx
7f 00 00
+13 L3 48 89 10 mov %rdx -> (%rax)[8byte]
+16 L3 d9 ee fldz $0.000000 -> %st0
+18 L3 b8 01 00 00 00 mov $0x00000001 -> %eax
+23 L3 83 f8 01 cmp %eax $0x00000001
+26 L4 @0x00007ff669685a40 0f 85 05 2f ee 7f jnz $0x00007ff6e956121b
+32 L4 @0x00007ff669685458 e9 ed 2e ee 7f jmp $0x00007ff6e9561202
END 0x00007ff6e95611e9

recreate_app -- found valid state pc 0x00007ff6e95611f6
recreate_app -- found ok pc 0x00007ff6e95611f6
recreate_app_pc -- translation is 0x00007ff6e95611f6
float_pc_update: translated 0x00007ff6697d17fc to 0x00007ff6e95611f6

dispatch: target = 0x00007ff6e9561214
```

It shouldn't be like #1427 b/c it's fxsave64. So why is the pc just
bottom 32 bits?

Separate run shows the exit reason is fxsave64:

```
FXSAVE64 intra is correctly handled
float_pc_update: 64-bit reason
FXSAVE64 inter is **incorrectly** handled
```

Just a reminder of the instru here. We pass a pointer to the base of the
fxsave64 destination to float_pc_update:

```
Fragment 3221, tag 0x00007ff6c7b2118b, flags 0x9000630, shared, size 37:
[common.floatpc.exe]
0x00007ff647d914e8 48 8b c1 mov %rcx -> %rax
0x00007ff647d914eb 48 ba 98 11 b2 c7 f6 mov $0x00007ff6c7b21198 -> %rdx
7f 00 00
0x00007ff647d914f5 48 89 10 mov %rdx -> (%rax)[8byte]
0x00007ff647d914f8 d9 ee fldz $0.000000 -> %st0
0x00007ff647d914fa b8 01 00 00 00 mov $0x00000001 -> %eax
0x00007ff647d914ff 83 f8 01 cmp %eax $0x00000001
0x00007ff647d91502 0f 85 0f 8b f5 ff jnz $0x00007ff647cea017
0x00007ff647d91508 e9 0a 8b f5 ff jmp $0x00007ff647cea017

Fragment 3222, tag 0x00007ff6c7b211a4, flags 0x10006b0, shared, size 73, cannot be trace:
[common.floatpc.exe]
0x00007ff647d91518 48 8b d4 mov %rsp -> %rdx
0x00007ff647d9151b 48 81 ec 10 02 00 00 sub $0x0000000000000210 %rsp -> %rsp
0x00007ff647d91522 48 83 e4 f0 and $0xfffffffffffffff0 %rsp -> %rsp
0x00007ff647d91526 65 48 89 3c 25 38 16 mov %rdi -> %gs:0x00001638[8byte]
00 00
0x00007ff647d9152f 65 48 8b 3c 25 40 16 mov %gs:0x00001640[8byte] -> %rdi
00 00
0x00007ff647d91538 66 c7 87 62 01 00 00 data16 mov $0x0003 -> 0x00000162(%rdi)[2byte]
03 00
0x00007ff647d91541 48 8d 3c 24 lea (%rsp) -> %rdi
0x00007ff647d91545 65 48 89 3c 25 28 16 mov %rdi -> %gs:0x00001628[8byte]
00 00
0x00007ff647d9154e 65 48 8b 3c 25 38 16 mov %gs:0x00001638[8byte] -> %rdi
00 00
0x00007ff647d91557 48 0f ae 04 24 fxsave64 -> (%rsp)[512byte]
0x00007ff647d9155c e9 cd 8a f5 ff jmp $0x00007ff647cea02e

float_pc_update: fp state 0x0000006a4116f5a0
recreate_app_pc -- translating from pc=0x00007ff647d914f8
```

So it's getting the actual pc written by fxsave64.
Could it be a vmware bug?
Never seen it on win7, but haven't run 1000x in a loop.
Why nondet?
Why limited to Windows (or is it?)?