A few minor tweaks in the language; note the existence of `clang-tidy`.

Mostly, this is a set of links to other, existing documentation.  However,
the GitHub web UI will recommend developers review this file before
submitting a pull-request.  It's a simple nudge to "do the right thing".

There was two problems with <iframe>:
  - In some cases an extra frame was drawn
  - Some browsers (chrome and Opera) , in some cases, did not display correctly the image (wrong size)

This was due to THashList::GetListForObject returning a list that contains more than just
the request objects.

This is useful know in order to avoid JSON conversion of colors (by JSROOT) if not needed.

When processing a TTree with TTreeProcessorMT, each thread creates
and uses its own TTreeView (by using a TThreadedObject<TTreeView>).

Until now, in the case of interleaved execution of tasks, the second
task could overwrite the first's TFile and TTree, causing crashes
when the first task resumed execution.

This commit modifies TTreeView so that it supports several tasks
opening and using different TFiles at the same time, solving the
issue described above.

Future commits will remove `fCurrentFile` and `fCurrentTree` altogether
in order to make TTreeView play nice with TBB tasks. Then it will make
little sense to pre-emptively open the first filename in each thread.

TTreeView's internal logic will be changed by future commits to play
nice with TBB tasks, and will not be able to provide the interface that
this logic was relying on.

Each TDF node keeps a thread-local tuple of TColumnValues. TColumnValues
read the values of a column for a certain entry, but entry ranges and
TTreeReader-related objects are _task_ local.

Before this change, in case of interleaved task execution, the second
task starting in a thread would re-initialize the TColumnValues and
 overwrite the previous task's settings.

Now TColumnValues deal with multiple initializations by keeping their
internal state in a stack: when a new task initializes a TColumnValue
it pushes the required values in the stack, when a task completes
execution it pops its values from the stack.

Note that interleaved TBB tasks always follow a last-to-start,
first-to-finish pattern, which allows us to use a LIFO structure for
TColumnValue.

This fixes a race condition in which a TTreeReader and its
TTreeReaderValues could be deleted concurrently:
Thread #1) a task ends and pushes back processing slot
Thread #2) a task starts and overwrites thread-local TTreeReaderValues
Thread #1) first task deletes TTreeReader