bugfix: condition variable sleep on unrelated mutex

In HttpClient::networkThread 's main loop:

```
        // step 1: send http request if the requestQueue isn't empty
        request = nullptr;
        
        s_requestQueueMutex.lock();
        
        //Get request task from queue
        
        if (!s_requestQueue->empty())
        {
            request = s_requestQueue->at(0);
            s_requestQueue->erase(0);
        }
        
        s_requestQueueMutex.unlock();

        if (nullptr == request)
        {
            // Wait for http request tasks from main thread
            std::unique_lock<std::mutex> lk(s_SleepMutex); 
            s_SleepCondition.wait(lk);
            continue;
        }
```

After `s_requestQueueMutex.unlock();` and before ` s_SleepCondition.wait(lk);`, there are chances that requests send through `HttpClient::send`. Then network thread will block on `s_SleepCondition` while there are requests in `s_requestQueue`.

This pull request just fix it.


There are other race conditions in this module for now, eg:
*   Between call sequences  `HttpClient::destroyInstance()` and `HttpClient::getInstance()->send()`, there are chances `s_requestQueue` is not `nullptr` in `HttpClient::lazyInitThreadSemphore`. So that new network thread is not started, while old network thread is about to terminated.
*   After `scheduler->performFunctionInCocosThread(CC_CALLBACK_0(HttpClient::dispatchResponseCallbacks, this));`, there is no guarantee that `this` is valid in `HttpClient::dispatchResponseCallbacks`.

The easiest way to suppress those is deleting public interface `HttpClient::destroyInstance`.

Also `s_cookieFilename` may not be thread-safe, it is depend on how `HttpClient::enableCookies` supposed to be called.
http://en.cppreference.com/w/cpp/thread/condition_variable_any/wait

template< class Lock >
void wait( Lock& lock );

Atomically releases lock, blocks the current executing thread, and adds it to the list of threads waiting on *this. The thread will be unblocked when notify_all() or notify_one() is executed. It may also be unblocked spuriously. When unblocked, regardless of the reason, lock is reacquired and wait exits.