acpi_ged: Handle events directly

acpi_ged:  Handle events directly

Handle ged interrupts directly from the interrupt handler,
while the interrupt source is masked, so as to conform
with the acpi spec, and avoid spurious interrupts and
lockups on boot.

When an acpi ged interrupt is encountered, the spec requires
the os (as stated in 5.6.4: General Purpose Event Handling)
to leave the interrupt source masked until it runs the
EOI handler.  This is not a good fit for our method of
queuing the work (including the EOI ack of the interrupt),
via the AcpiOsExecute() taskqueue mechanism.

Note this fixes a bug where an arm64 server could lock up if
it encountered a ged interrupt at boot.  The lockup was
due to running on a single core (due to arm64 not using
EARLY_AP_STARTUP), and due to that core encountering a
new interrupt each time the interrupt handler unmasked
the interrupt source, and having the EOI queued on a taskqueue
which never got a chance to run. This is also possible
on any platform when using just a single processor.
The symptom of this is a lockup at boot, with:
"AcpiOsExecute: failed to enqueue task, consider
increasing the debug.acpi.max_tasks tunable" scrolling
on console.

Similarly, spurious interrupts would occur when running
with multiple cores, because it was likely that the
interrupt would fire again immediately, before the
ged task could be run, and before an EOI could be sent
to lower the interrupt line.  I would typically see
3-5 copies of every ged event due to this issue.

This adds a tunable, debug.acpi.ged_defer, which can be
set to 1 to restore the old behavior.  This was done
because acpi is a complex system, and it may be
theoretically possible something the ged handler does
may sleep (though I cannot easily find anthing by inspection).

MFC after: 1 month
Reviewed by: andrew, jhb, imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42158