Only in such mode multithreading is allowed. 
In async mode one can meaningfully use send completion callback.
Default mode is synchronous (as before), which allows to use handler
only from main thread

Now no queues are allowed, all operation are confirmed by WS handler

Now one can directly register WS handlers to THttpServer
If allowed, handlers can be precessed directly in the civetweb threads
without involving of THttpServer thread at all. 
This allows to run many connections for many different web widgets
absolutely independent from each other - there are no one bottleneck in
http thread (or any other main thread)

THttpServer::SetTerminate() should only be used when really terminating
application. In such mode connections and websockets not cleaned up
properly

Signed-off-by: Olivier Couet <olivier.couet@gmail.com>

Set ownership and websocket ID directly in that method

It is small sub-class, which allows to start http server like: 

    new THttpServer("https:4567?ssl_cert=certificate.pem");

Certificate should be provided in any case

Let set text, xml, json, binary content types and content itself

By using THttpCallArg::SetPostData(std::string &&buf) signature, one
clearly identify that value will be moved and invalid afterwards

To clarify ownership, one uses shared_ptr.
Keep old interfaces, but declare them as deprecated. 

One could send now binary messages viw websockets, 
which result as Blob objects on JavaScript side. 
Also combined send of string header and raw buffer will be supported.
For special engines (like longpoll) this will be handled in single
request.

Now it is fully internall class, which should be used only by framework.
Use THttpWSHandler to work with websockets

remove inheritance from TNamed, 
change signature of PreviewData() and PostProcess() methods

Hash used as unique identifier for websocket

Do not try to process websocket close synchronousely. 
It is anyway last action with websocket and does not require that
calling thread blocks. Additional protection for the case of shutdown 
of THttpServer with running websockets

Formally is not required. Could help to detect cardinal failure early

At this moment ROOT event loop may not be active and therefore requests
are not processed. Problem appeared with the opened websockets -
civetweb invoke close handler at the end, which hangs

It returns two dummy bytes 3 and 233(-23), which should be handled as
closed connection. Detected with different browsers, probably will be
improved in next civetweb releases

It can be specified as extra option of THttpServer itself like:

   new THttpServer("http:8080;cors")
   
But also as in original code:   

   new THttpServer("http:8080?cors")
   
Second form is formally belongs to the TCivetweb engine and now handled
appropriately