Update use of AcpiOsWaitEventsComplete interface.

This patch cleans up all of the AcpiOsWaitEventsComplete() invocations to
make it to be invoked inside of ACPICA in the way to accommodate Linux's
work queue implementation.

According to the report, current Linux kernel code is facing a boot time
race issue in the AcpiRemoveNotifyHandler().  This is because:
Linux is using work queues to implement a deferred handler call environment
while ACPICA expects OSPM to implement AcpiOsWaitEventsComplete() using
wait queues.  The position to invoke a "waiter" is not suitable for a
"flusher" as new invocations can be scheduled after this position and
before the deletion of the handler from its management container.

Since the following commit has deleted AcpiOsWaitEventsComplete()
parameters, it thus might not be possible for OSPM to achieve a safe
removal using wait queues.  This requires ACPICA to be changed accordingly
to "flush" handlers rather than "wait" them to be drain up:

  Commit: 5ff986a2a9db11858247b71fe242fe17617229aa
  Date: Wed, 16 May 2012 13:36:07 -0700
  Subject: Introduce AcpiOsWaitEventsComplete interface.

  This interface will block until asynchronous events like notifies
  and GPEs are complete. Within ACPICA, it is called before a notify or GPE
  handler is removed. ACPICA BZ 868.

This patch fixes this issue by invoking AcpiOsWaitEventsComplete() in the
way to "flush" things - it thus should be put to the position after handler
is removed from its management container but before it is destructed.

The technical concerns are:
1. MTX_NAMESPACE is used to protect things that AcpiOsWaitEventsComplete()
   might be waiting for, thus MTX_NAMESPACE must be unlocked before
   invoking AcpiOsWaitEventsComplete().
2. MTX_NAMESPACE is also used to implement the serialization of
   AcpiInstallNotifyHandler() and AcpiRemoveNotifyHandler().  This patch
   changes this logic, thus if there are many
   AcpiInstall/RemoveNotifyHandler() invoked in parallel, the
   AcpiOsWaitEventsComplete() might face the races which could cause it
   never running to an end.  Normally this will require additional code to
   implement a separate locking facility which is not implemented due to 3.
3. Given ACPICA users will always invoke AcpiInstallNotifyHandler() once
   during Linux module/device initialization and invoke
   AcpiRemoveNotifyHandler() once during module/device finalization,
   problem stated in 2 will not happen in Linux environment due to the
   mutual exclusive module/device existence, this fix thus is sufficient.
Same concerns can apply to AcpiInstall/RemoveGpeHandler().  Reported and
tested: Ronald Vink.  Fixed: Lv Zheng.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=60583
Signed-off-by: Lv Zheng <lv.zheng@intel.com>