add KVM cherry-pick for Windows live-migration

add KVM cherry-pick for Windows live-migration

the following three cherry-picks from 4.6, first introduced
in Ubuntu-4.4.0-63.84 to fix LP#1649718 break Windows live
migration:

commit 296cb660d22c3732e08464f456d9336392b94c60
    kvm: x86: Check dest_map->vector to match eoi signals for rtc
    (cherry picked from commit 4d99ba898dd0c521ca6cdfdde55c9b58aea3cb3d)

commit f05aa1ca76109353c9421dfe1421d2fa42bd1605
    kvm: x86: Track irq vectors in ioapic->rtc_status.dest_map
    (cherry picked from commit 9daa50076f585854f0040aa8403eac020d6f5d64)

commit aee4b7a8ebc1496f55299241ba96590f80acdc19
    kvm: x86: Convert ioapic->rtc_status.dest_map to a struct
    (cherry picked from commit 9e4aabe2bb3454c83dac8139cf9974503ee044db)

cherry-pick a follow up commit from Linux 4.8, which fixes
the issue:

b0eaf4506f5f95d15d6731d72c0ddf4a2179eefa
    kvm: x86: correctly reset dest_map->vector when restoring LAPIC state

    When userspace sends KVM_SET_LAPIC, KVM schedules a check between
    the vCPU's IRR and ISR and the IOAPIC redirection table, in order
    to re-establish the IOAPIC's dest_map (the list of CPUs servicing
    the real-time clock interrupt with the corresponding vectors).

    However, __rtc_irq_eoi_tracking_restore_one was forgetting to
    set dest_map->vectors.  Because of this, the IOAPIC did not process
    the real-time clock interrupt EOI, ioapic->rtc_status.pending_eoi
    got stuck at a non-zero value, and further RTC interrupts were
    reported to userspace as coalesced.

    Fixes: 9e4aabe2bb3454c83dac8139cf9974503ee044db
    Fixes: 4d99ba898dd0c521ca6cdfdde55c9b58aea3cb3d