- Only rely on presence of TMCManager in multi run (PR#6 in vmc-project/vmc)
- Withdraw unwanted TMCVerbose modifications to avoid changes in the tests outputs
- Recover TGeoManager::fIsOutside for transfer tracks (PR#3 in vmc-project/vmc)

Some Pythia8 headers expose an unfortunate "using namespace Pythia8".
This triggers:
In file included from /root/ship-log-keep/sw/slc7_x86-64/ROOT/master_FAIRSHIP-1/include/TMCManager.h:26:
/root/ship-log-keep/sw/slc7_x86-64/ROOT/master_FAIRSHIP-1/include/TMCParticleStatus.h:81:7: error: reference to 'Info' is ambiguous
      Info("Print", "Status of track");
      ^
/root/ship-log-keep/sw/BUILD/b61305e07edfb1f9a906335e2093ac409db3c4cc/ROOT/include/TError.h:58:13: note: candidate found by name lookup is 'Info'
extern void Info(const char *location, const char *msgfmt, ...)
            ^
/root/ship-log-keep/sw/slc7_x86-64/pythia/v8230-ship-1/include/Pythia8/Info.h:30:7: note: candidate found by name lookup is 'Pythia8::Info'
class Info {
      ^

By explicitly requesting "::Info" that ambiguity should be resolved.

Now that ROOT_GENERATE_DICTIONARY() knows how to pick up includes
and compile definitions from the library targets even when added
later with target_link_libraries() and target_include_directories(),
we can remove extra includes added by hand as a workaround before.

This function is needed for newly introduced sensitive detectors framework
to provide a hook for a central call to fill ROOT trees before resetting data
in sensitive detector's end of event.

The index of the geometry state belonging to a track is now reset
properly when the TMCManagerStack is notified on the restored geometry.

this will allow to maintain a standalone version of VMC in parallel, which can be then tagged more frequently according to the needs of the VMC project

Moved README.md added with Multiple Engines development in README.multiple.md and added a new README.md (Md version of the Drupal VMC main page)

Moved TPDGCode.h (used in 'pythia6' and 'pythia8') from 'vmc' to to 'eg'; this makes all other libraries in 'montecarlo' not dependent on 'vmc'

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.

A plain include_directories() was meant to be converted
into target_include_directories() in the previous commit,
but the second part was missing.

- this should address the ROOT-9681 JIRA item

Details:
- Added support for user defined sensitive detectors
  o TVirtualMCSensitiveDetector: the interface class for a user sensitive detector
  o New functions in TVirtualMC:
     void SetSensitiveDetector(const TString &volName, TVirtualMCSensitiveDetector *sd);
     TVirtualMCSensitiveDetector *GetSensitiveDetector(const TString &volName) const;
     void SetExclusiveSDScoring(Bool_t exclusiveSDScoring);
  o New function in TVirtualMCApplication:
     void ConstructSensitiveDetectors();
- Added new TVirtualMC::NIELEdep() function
- Removed default implementation for  TVirtualMC::TrackPosition/Momentum with Float_t arguments

request from ALICE O2

This refactors the CMake build files to no longer manually call
the CMake functions for generating and linking the dicionairies.
One reason is to reduce boilerplate, the other is that it is now
no longer possible to have naming mismatches between the dictionary
generation arguments and linking function arguments which was causing
the race conditions we had in our build system.

This also now follows more strictly the separation between dependencies
like Math, Tree and Core and pure linking flags to external libraries.

The naming of the library in the two function calls ROOT_GENERATE_DICTIONARY
and ROOT_LINKER_LIBRARY was often not matching. This causes that
ROOT_LINKER_LIBRARY couldn't correctly set its dependencies to the output
file of ROOT_GENERATE_DICTIONARY and therefore causes race conditions in
the build system.

Note: We're attached all dependencies to a custom target, and
NOT to the output files generated by rootcling. This should mitigate
the race conditions we experience when multiple targets in different
Make jobs request the same output file as a dependency and then
suffer from this Make problem that is described here:
https://cmake.org/Bug/view.php?id=10082

This patch also adds a (commented out) piece of code that can print
warnings if we don't have a fitting G__*.cxx file for a
ROOT_LINKER_LIBRARY call. This is sometimes intended, so I didn't
enable this warning by default. We should enable this code
by default in the future once we have a way to express if we
intentionally don't provide the G__*.cxx file when calling
ROOT_LINKER_LIBRARY.

ROOT_GENERATE_DICTIONARY allows to specify dependencies, but we currently
don't actually specify those. As we need this for getting the module
dependencies right (as we can't build missing modules on demand), we should
add those dependencies here. Then those dependencies propagate to the
rootcling invocation which will in the future also generate the C++ module
for the selected dictionary.

ClassImp is a macro defined in Rtypes.h. It can be written without trailing
semicolon. However, clang-format is based on lexing and it doesn't know at
all about preprocessors and how to expand macros. When visiting ClassImp(X)
it thinks this is not a completed entity (as it doesn't expand macros) and
considers the next line as continuation of the previous.

Inserting a semicolon fixes the issue and makes formatting with clang-format
in the ROOT codebase less tricky.

(previously distributed in geant4_vmc/mtroot)