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

This allows to run data transfer to each connection in separate threads

While some structures of TWebWindow could be accessed from different
threads, introduce mutex which protects list of connections. 
List of connections itself now is vector of shread_ptr. This allows to
have reference on connection from different thread.
One still need to introduce separate mutex for connection data.
Of course one should avoid acquiring of several mutexes at same time.

ROOT-9620 #close

 Fix in LLVM trunk: https://reviews.llvm.org/rL317091

- RResultPtr now stores a raw pointer intead of a weak_ptr
- weak_ptr validity checks have been removed since RLoopManager cannot
  go out of scope before these other entities