WifiManager: Remove static objects

Thanks to b/24334032, we know that there can be more than one
WifiManager object per process.  Also, due to b/19159232 we know
that holding static references to contexts within WifiManager is
not okay.  This CL addresses both issues by correctly implementing
Wifimanager as the per-context CachedService as it is instantiated
in SystemServiceRegistry.

To do this, all previously static object members of WifiManager
are converted to non-static.  This is primarily safe since:

  - In processes which only instantiated WifiManager from a single
    context, the behavior is functionally identical between the
    static and non-static implementation.

  - In situations where multiple WifiManager objects were created,
    this is not a real issue:

    + sListenerKey is okay to be tracked per-instance since it
      only tracks replies for asynchronous outgoing calls for a
      single WifiManager instance (replies are not multicast to
      all instances within a pid, since replies from
      WifiServiceImpl are addressed to the other end of the
      AsyncConnection the request message came from).
    + The same is true of sListenerMap and sListenerMapLock
    + Having a per-WifiManager-instance mAsyncChannel is at worst
      a small linear increase with the number of contexts that
      use WifiManager, but for the vast majority of processes will
      not be an increase at all.
    + Having a thread per WifiManager is something that has been
      brought up in the past (b/25644527 comes to mind).  I think
      we should continue to track that particular problem there.

One static was added: an sServiceHandlerDispatchLock which ensures
that listeners from multiple ServiceHandler threads will be called
sequentially instead of interleaved.  Since ServiceHandler was
previously static, this preserves the behavior where multiple
WifiManager objects would not deliver callbacks in parallel.

BUG=19159232
BUG=24334032

Change-Id: I24125a285f97e0c5b3ca4fd721ba8ed19aa245e9