xen/intr: merge parts of resume functionality into new function

[ehem_freebsd_m5p.com]

Summary

The portions of xen_rebind_ipi() and xen_rebind_virq() were already
near-identical. While xen_rebind_ipi() should panic() on
single-processor, still having the functionality to invoke seems
harmless.

Meanwhile much of the loop from xen_intr_resume() seemed to want to be
closer to this same code. This pushes related bits closer together.

[ehem_freebsd_m5p.com]

Fixing a bug which was found while glancing at this delta.

[ehem_freebsd_m5p.com]

Removing one line which really should have been removed before.

[ehem_freebsd_m5p.com]

Move the isrc->xi_cpu = 0; line lower, hopefully hinting this is part of the xen_intr_assign_cpu() call.

[ehem_freebsd_m5p.com]

Small update, keep panic strings closer to original, but add function name. Should make diagnosis easier if this ever gets triggered.

[ehem_freebsd_m5p.com]

Fix a potential unused variable warning. Single-processor systems almost seem archaic, but we should still function on such.

[ehem_freebsd_m5p.com]

Remove a bit more unused in case of uniprocessor code from uniprocessor builds. Such are actually rather more sensible in case of virtual machines...

[ehem_freebsd_m5p.com]

Ugh! Hopefully finish the hunt for bits which disappear if uniprocessor.

[ehem_freebsd_m5p.com]

Fixing issue discovered during review. The blanket wipe of ->xi_port in xen_intr_resume() can't be removed until D30599.

[ehem_freebsd_m5p.com]

I'm wondering if I should merge D30599 into D30598. D30598 is simply a precursor to implementing D30599.

[ehem_freebsd_m5p.com]

Another signed/unsigned update, sorry.

[ehem_freebsd_m5p.com]

Another small update for the sign auditing.

[ehem_freebsd_m5p.com]

sys/x86/xen/xen_intr.c

748–749

Based on what I saw in D32866, I suspect there should be a intr_event_bind() here.

[ehem_freebsd_m5p.com]

Updating to ensure consistency with what I've got. Should still apply, but updates on D30743 have made application unclean.