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.

In 46ba2eef, RooAbsCollection was added to the RooFit target,
probably by mistake. It resides in RooFitCore.

After removing some CMake header cheating code, the headers in res/
became invisible across RooFit packages. Here, they are added to the
interface of the respective RooFit targets, but only for the
BUILD_INTERFACE.
This is OK as long as these headers will only be included in .cxx of
RooFit.

RooFitCore + its dependencies use headers from RooBatchCompute. The
dependency was private before, but now that include directories are
not anymore cheated into every target, the dependency had to be made
public.

The test claims to have no python dependencies, but it was importing
numpy for no reason.

If we fail to generate the TEmulatedTuple, do not set the TClass's fClassInfo (previously it was actually
set to a ClassInfo pointing to the ... global namespace!

The translation unit (name == ) is a decl context which returns nullptr for getDeclContext

Its Python 3.11 needs the upcoming Spark release, see https://github.com/apache/spark/pull/38987