* Avoid recursive powershell.exe

This prevent having up to 400 powershell instances when building ROOT (when calling `root-config --has-whatever`)

* Another try (thanks Ole)

Declaring functions in the LinkDef is not necessary anymore since ROOT 6
with cling.

Now that the file history for git was destroyed anyway by moving these
files, we might as well format them.

There is a dependency problem between the RooFit packages that will
start to annoy us soon. Right now, RooFitHS3 depends on both RooFitCore,
RooFit, and RooStats.

But to really have nice interfaces for the JSON IO that can be used from
the workspace directly (like `ws.writeToFile("ws.json")`), RooFitHS3
needs to be merged with RooFitCore at some point.

As of now, this would not work, because then there would be a circular
dependency between RooStats and RooFitCore.

This can be avoided by moving the `RooStats::ModelConfig` class from
RooStats to RooFitCore, avoiding the dependency of RooFitHS3 on
RooStats.

Some arguments to make for this case:

  * The ModelConfig is strongly connected to the RooWorkspace, because
    people often use it to save model "metadata" in the workspace

  * RooFit is often said to be for "model building" and RooStats for
    statisitcal procedures. Specifying model details in the
    configuration object is part of model building.

  * Also HistFactory depends on RooStats, but only for the ModelConfig
    and the Asimov dataset generation. By moving the ModelConfig to
    RooFit, we are also half way done avoiding the dependency of
    HistFactory on RooStats.

  * The only thing that people use from RooStats is often only the
    ModelConfig anyway, because it lets them specify analysis details in
    the workspace, and then the analysis is done with other frameworks.

* protect graph2d against gPad=0

* protect DistanceToPrimitive

dedent does not work because {log} is not indented.

Fix several `warning C5033: 'register' is no longer a supported storage class` in asimage

Co-authored-by: Javier Lopez-Gomez <javier.lopez.gomez@cern.ch>

Co-authored-by: Philippe Canal <pcanal@fnal.gov>

Co-authored-by: Philippe Canal <pcanal@fnal.gov>

It doesn't make sense to have the weight variable in the set of
observables. This causes problems in various places, e.g.:

  * this dummy `weightVar` is polluting the JSON file when exporting the
    workspace

  * it is a nuisance for normalization because it will also appear in
    the normalization sets

This commit suggests to not add some dummy weight variable to the
workspace.

  * fix invalid memory access in RooFuncWrapper by getting observables
    and parameters of the original function, and not the one that is
    compiled for a normalization set, which is temporary.
    What matters are the names of the parameters and observables, and
    they are the same anyway

  * new `CodeSquashContext::buildCall()` function to avoid code
    duplication

  * add support for `RooExponential`, including unit test

When used with `target_include_directories`, the generator
expression `$<BUILD_INTERFACE:...>` only works with one
directory as argument (as least as used here in the previous code)

`target_include_directories` detects wheter the argument is
a full pathname, a relative path or a generator expression.
In the 1st and 3rd cases it uses the argument as is.
In the 2nd case it prefixes the arguement with the local directory.

When BUILD_INTERFACE has more than one directory (as used here,
meaning in practice that the argument ends up with a semi colon),
the argument is thought (by CMake) to be a relative path and prefix
it with the current directory.

This means that the include directory properties of the buitin XRootd
ends up with:

/nashome/p/pcanal/root/builtins/xrootd/$<BUILD_INTERFACE:/nashome/p/pcanal/geant/gcc10/builds/opt/root-ninja/builtins/xrootd/XROOTD-prefix/include/xrootd;/nashome/p/pcanal/geant/gcc10/builds/opt/root-ninja/builtins/xrootd/XROOTD-prefix/include/xrootd/private>

This allow to apply to all usage place support for the BUILD_INTERFACE having several
elements.

Provide special handler like for TAttLine or TAttFill
Let use generic GED for TAttText
Interactivity for TDiamond
Click handling for TGaxis
Proper draw option for TH1 with and without filled fSumw2

There are differences between TGaxis and TAxis classes,
which should be handled

Take into account that each fragment load async and await it

For classes like TPaveText or TLegend one can now edit
font size, color and face.