Often, when designing an analysis, it happens to deal with empty RVec instances,
for example after a selection cut. This change allows in an ergonomic way to
deal with this case without imposing overhead on the user.

* Fix bad formulas/typos in docs, clarify SplitRange() feature of RooAbsPdf.

* Typos, misplaced comments, clarifications.

This was not causing the observed failures.

This reverts commit ede6463b.

in order to make the interactive experience in python and at the
prompt more rewarding:
```
root [0] ROOT::Math::XYZTVector v
(ROOT::Math::XYZTVector &) (0,0,0,0)
```

this commit suggests to prefer the usage of ROOT::Math::TLorentzVector
specialisations instead of the TLorentzVector class given the
advantages of the former.
- Release notes are changes
- The documentation of TLorentzVector updated to point to the specialisations of ROOT::Math::TLorentzVector
- The RDF tutorials using TLorentzVector upgraded

This reverts commit 2b071027.

Try to appease the incremental builds. They fail with:

In file included from test_Persistency1_C_ACLiC_dict dictionary payload:7:
./test_Persistency1.C:69:8: error: redefinition of 'Event'
struct Event : public DataObject  {
       ^
/.../roottest/root/tree/cache/Event.h:103:7: note: previous definition is here
class Event : public TObject {
      ^
In file included from test_Persistency1_C_ACLiC_dict dictionary payload:7:
./test_Persistency1.C:86:8: error: no member named 'm_evt' in 'Event'
    d->m_evt = d->m_run = i;

to get better performance.

This fixes ROOT-10057

/build/jenkins/night/LABEL/mac1014/SPEC/cxxmod-noimt/root/test/testGenVectorVc.cxx:194:1: error: redefinition of 'Point' as different kind of symbol
using Point = ROOT::Math::PositionVector3D<ROOT::Math::Cartesian3D<T>, ROOT::Math::DefaultCoordinateSystemTag>;
^
In module 'Darwin' imported from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/assert.h:42:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/MacTypes.h:538:8: note: previous definition is here
struct Point {
^

See  http://root-forum.cern.ch/t/tselector-ttreereader-and-fchain-setentry/30170/1
and http://root-forum.cern.ch/t/problem-with-multiple-files-in-tchain-with-makeselector-class/32534/7

Without this patch for Name<Content>::Inner, MakeProject was using Name<Content,::Inner>::Inner.

in order to make of this code the most up-to-date set of examples possible.

GetEntry is not thread-safe anyway, and GetEntriesUnsafe is faster.

GetEntriesFast is not as fast as it could be: it constructs and
destructs a TReadLockGuard, and might need to modify fLast.
GetEntriesUnsafe is a thread-unsafe version of GetEntriesFast
that side-steps these operations when possible.

The operation is relatively costly as TObjArray::GetEntries also
creates a TReadLockGuard.

From V.Vasilev, it fixes:
[ 72%] Building CXX object interpreter/llvm/src/tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenModule.cpp.o
While building module 'Cling_Interpreter' imported from /.../root/core/clingutils/src/RStl.cxx:25:
In file included from <module-includes>:5:
 /.../root/interpreter/cling/include/cling/Interpreter/RuntimeUniverse.h:13:2: error: "This file must not be included by compiled programs."
 #error "This file must not be included by compiled programs."
 ^

...wherever it's more readable, less error-prone than the alternatives.

This is an extension allowing the VMC package to run a simulation
with multiple different engines at a time. Tracks can be transferred
among engines during a simulation run based on conditions specified by
the user.

Important notes on the extensions:
  1) This extension preserves backward-compatibility in the sense that
     user code relying on the former version of VMC is still running
     with the extended version. Was tested with GEANT3_VMC@v2-6 and
     GEANT4_VMC@v3-6-p1.
  2) A shared simulation is only possible when TGeo is used for geometry
     construction and navigation.
  3) A TMCManager singleton object is responsible for handling multiple
     engines and can be obtained on request calling
     TVirtualMCApplication::RequestManager() during construction of the
     user application class.
  4) The introduced TMCParticleStatus objects hold additional
     information to keep track of properties when a track is transferred
     between engines.
  5) When a track is interrupted in one engine to be transferred to
     another, the geometry state is cached in the form of a
     TGeoBranchArray object. It will be used to initialize the navigator
     when this track is picked up for further transport in the next
     engine. This is especially useful/required when a track is
     transferred at a volume boundary in order to be picked up in the
     entered volume and not in the one just left. This is a main reason
     why geometry management is forced to be done via TGeo.

A more comprehensive introduction concerning the usage and
implementation in the user code can be found in the
montecarlo/vmc/README.md

Further note:
  This commit also applies the clang format to the modified and new
  files.