Improved documentation, made minor changes to spelling.

Copying fBlockList from orig.GetEND() is currect in this case: orig has only one TMemBlock,
and fExternalData->data() and size() will be the same for any reference to that data.

Reduce code dupe across ctors by introducing common option handlingi.

white spaces

the argument --cuda-host-only and the default c++ stardard will be set at start of cling -xcuda

set the AuxTarget, if the LangOpt CUDA is true and enable the compilation of cuda runtime code
needs a preload of the libcudart.so and the arguments -std=c++11 and --cuda-host-only at start of cling

In some cases where the memory available to the TTreeCache can not fit the entirety
of (potentially odd-shaped) cluster, the TTreeCache could end up with a situation
where (starting at some point) it is invalidated at each entry *and* the basket
from the previous cluster boundary up to some entry number less than the current
entry are loaded over and over again (until the entry number reaches the next cluster
boundary).

In a case encountered by CMS, a TTree has a recorded cluster size of 165 events.  However the TTree
appears to not have been clustered; most basket size are the same and seem to be flushed at 139 events
interval.  A few branches are flushed less frequently, for example EventAuxiliary is flushed every 459
entries.

As a consequence when entry 417 is requested, the cluster boundary is calculated as 330 and
the first end as 495.  Then all basket containing entries in that range are loaded, including
EventAuxiliary's basket containing entries 459 to 917.  Then 917 is the highest available (partial)
entry available.  Thus the next time the TTreeCache is invalidated is when entry 918 is requested.
As that point the cluster boundary is calculated as 845 and the first end as 495, however
(with the small enough TTreeCache size), the cache is full as soon as the basket for EventAuxiliary
is added.  This resulted in a 'valid' range for this cache of 845 to 917 and lead to the reading
all the baskets added so far ... and thus eventhough none of them would be used for reading
and they already had been read once in memory.  Then for entry 919, the exact same behavior
repeated.

The solution consist on marking the 'minimum' valid range as being 'at least' one cluster wide.

Thus in the example above for entry 918 through 989, **only** the missing baskets are read
individually resulting in 'degraded' performance but **not** a wild over-read.

A future enhancement would be, in those cases, restart the next buffer from the last valid
entry + 1 rather than the previous event boundary.  This would result in a 'slightly' over-read
(some baskets might be read twice) rather than the wild useless over-read we had.

It was unusable due to a typo

The logic to get the typename of a TTree leaf/branch is now factored
out into its own function, has been streamlined, and support for
leafnames with multiple dots ("b1.b2.leaf") has been added.

This patch let you customize your kernel:
```
{
  "display_name": "C++14-custom",
  "argv": [
      "jupyter-cling-kernel",
      "-f",
      "{connection_file}",
      "--std=c++14"
  ],
  "language": "C++",
  "env": {"CLING_OPTS": "-I<add_directory_to_include_search_path> -L<add_directory_to_library_search_path>"}
}
```