Instead of using static variables just configure gEnv->SetValue()
parameters directly. Adjust tutorial

Always use mutex to protect vector of canvases 

This method is thread safe

Fixes several issues with drawing and update of superimposed histograms

works

Instead of starting every new thread for new operation - reuse same
thread which was started during first send operation.

Also take care that such dedicated threads correctly stopped when
WSHandler is destroyed

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

Before one could submit as many operation as one wants to the websocket.
In case of longpoll socket this lead to extra queue, which was not
controlled by the user. 

Now each send operation is confirmed by callback. Only after such
callback next send operation via websocket is allowed. Queue is
organized externally (like in TWebWindow). 

For the longpoll engine this simplify internal logic and avoids queueing

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

It defines, if window run its code in separate thread

Now URL to the webwindow is shorter and like:
http://server/win1/

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)

Provide methods to configure extra thread for THttpServer (default off)
and extra threads for clients sending (default off). Same configuration
can be done via .rootrc file

RCanvas::Run(doble) runs canvas functionality for specified time, 
must be regularly called when canvas should be used from user thread

RCanvas::Remove() method remove canvas from global lists, let destroy
canvas regularly

Update tutorials/v7/draw_mt.cxx macro

It allows to run webwindow functionality in non-main thread.
When no connection exists - just do sleep for specified time.
Should be regularly called

Mutex is booked in the beginning of operation and unbooked at the end
with specialized guard class. This prevents from complete locking of the
mutex for very long time

operations

Depending from caller thread, also invoke gSystem->ProcessEvents()

In multithreaded environment user data callback invoked not necessary
from the thread where data is received (typically THttpThread) but from
thread where TWebWindow is running. For that special queue is created
and Sync() function is introduced. 

Still open question - how to correctly detect main thread, where system
events should be processed when blocking function is called

In that folder all objects are registered, used by THttpServer
This allows to avoid all kind of global lists and exclude interfereance
between different instances of THttpServer. 
Such feature of main importance for TWebWindow(s), which should be
possible to run from many threads without interfearing with gROOT

To avoid 100% of CPU usage, made regulat short sleeps for 1ms

Should be used only with default sniffer, which does not have access to
any global lists

While websockets can run in multiple threads, one should clearly
identify instance as disabled

If websocket send operation was submitted into other thread, one have to
wait it completion before next send operation can be performed

web socket engine should support this (default off) and
web socket handler have to allow this

TWebWindow