xen/intr: move x86-only variable out of common

[ehem_freebsd_m5p.com]

Summary

Commit 27c36a12f1584b53d2454dac238eeed3dedc82ba is an x86-only feature.
As such xen_evtchn_needs_ack should only exist on x86.

[ehem_freebsd_m5p.com]

In case it isn't obvious, I'm pulling the more compelling portions of my work on sys/x86/xen/xen_intr.c|sys/xen/xen_intr.c through the relocation step. Whether sys/x86/xen/xen_intr.c file gets relocated to sys/xen/xen_intr.c, or sys/xen/xen_intr.c ends up being a complete rework this portion will be needed.

[ehem_freebsd_m5p.com]

Another spot which showed up on a more recent test.

[ehem_freebsd_m5p.com]

This is an early phase of getting interrupts operational on ARM. Simply figuring out which functions are actually used in common files (or in case of xen_intr_handle_upcall() needs to be invoked). @julien_xen.org originally implemented it as moving sys/x86/xen/xen_intr.c to sys/xen/xen_intr.c, but I'm wondering whether it is better to start from scratch. The #ifdef in sys/x86/xen/xen_intr.c is a precursor to @julien_xen.org's approach. If it was reimplemented from scratch that would end up useless, but for now I'm keeping that option open.

[ehem_freebsd_m5p.com]

Update due to PVHv1 removal. Quite the chunk of xen_intr_x86.h disappeared
due to the removal of PVHv1. I now wonder if the declaration of
xen_intr_alloc_and_bind_ipi() should be moved to x86/xen-os.h, this might
make other pieces cleaner.

[ehem_freebsd_m5p.com]

Needed to update the commit message too. That also shrinks due to removals.

[ehem_freebsd_m5p.com]

Rebalancing between D29913 and D30605; D29913 should really only be the variable move.