intr/x86: merge pic_{dis,en}able_source() call into pic_{dis,en}able_intr()

[ehem_freebsd_m5p.com]

Summary

When pic_{dis,en}able_intr() are called, they are paired with
pic_{dis,en}able_source() calls. Let the PIC implementations handle
calling of the second function.

Significantly, the pic_disable_source() calls paired with the
pic_disable_intr() calls are the only time PIC_NO_EOI was used. This
means the enum can be removed and pic_disable_source()'s prototype can
be simplified. Crucially, this means pic_disable_source() matches the
(*pre_ithread)() function of intr_event_create().

[ehem_freebsd_m5p.com]

Mostly looking for a review from @royger I'm unsure whether this additional call really needs to be retained, versus being unnecessary.

For for information on where this is headed: https://github.com/freebsd/freebsd-src/pull/1457

sys/x86/xen/xen_arch_intr.c

191

I'm unsure of this. intr_remove_handler() would previously end up calling xen_intr_pic_disable_source() after the xen_intr_pic_disable_intr() call, but I'm unsure whether this is actually needed. Does the source really need to be masked before the port is?

[ehem_freebsd_m5p.com]

Note to anyone else who happens to run across this. Indeed, (mask_fn)isrc->is_pic->pic_disable_source could be substituted for the intr_disable_srcargument to intr_event_create() inside intr_register_source(). Issue is after this commit, #1457 first modifies intr_disable_src and then later completely removes it. At the point where this is the wrapper still needs to be retained.