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.
@kezhuw 
How do you think of @Dhilan007 's comment?