if sender thread was started, one have to call join it - even when
thread function was normally returned

If does not respond after specified time - kill it

Probably, one could create special class for canvas

This items not need to be shared outside connection mutex

Does not work for now, may be later better solution will be found

In normall condition headless chrome immediately exits after page and
all scripts are loaded. To keep it running, special flag was used
enabling debugging mode and external ports. 

Much better solution - append special script to the page which never
loads. Chrome will keep running forever - until we kill it.

Required for headless browser.
Must be carefully done, while requests processing performed from
THttpServer thread

This is special requests, which does not processed immediately but hold
for the long time by the receiver. 

For the moment used in RWebWindow to hold headless browser until
processing is done

Some browsers (like newer Chrome) make fragmentation on chunks of 120KB. 
In the handler one need to combine chunks together before providing to
user code

Then connection is closed by client or when batch job is completed,
one can try to delete temporary profile for that job, which can be
about 30 MB.

Otherwise firefox always tries to access default profile, 
which is in many cases not a proper way. 

It replaced --remote-debugging-socket-fd from previous chrome versions.
It is workaround to let chrome runs longer in batch mode
Probably better solution can be implemented - with support from the
server side

Added --version to TApplicattion

Included commit hash and architecture

removed mistake

...as the presence of a datasource changes the type of RInterface.

It triggers wrong behaviour of Jenkins parser together with CDash adding ANSI escape symbols: NON-XML-CHAR-0x1B][0m[NON-XML-CHAR-0x1B]

GetSize is deprecated from 3.3
(https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_GetSize) and
the new recommendation is to use PyUnicode_GetLength.

Ensure that variables are actually read from the TTree...

Based on the solution exposed here: https://github.com/root-project/root/commit/9339de9e644b06d5f77607f83aea118969cab7b6

this has been resolved relying on value printing itself for the individual items.