This deals with the fact that our modulemaps include headers which can vary
across library versions and that attribute is a way to express this.

In C++20, `MakeField({"a","b"}` could mean "construct a pair" or "construct a
string_view from two iterators (aka `const char*`)". To avoid this (nonesense)
ambiguity, introduce a dedicated type that takes either a single `const char*`
or `string_view` as name, or two `string_views` as name/description.

C++20 has added the `string_view(const char*, const char*)` ctor, rendering calls
to these functions that pass two `vector` elements ambiguous with the `string_view` overload.
Work around this by adding an explicit initializer_list overload - that is the best
option I can think of.

I notified WG21-lib of this terrible breakage when going from C++17 to 20.

C++20 span ctor requires double curly `FillN({{1., 2.}})`.
Adding this overload resolves this.

This reverts commit f6327a6e.

This reverts commit 4a3258a4.

This reverts commit 85177f4f.
Re-enable C++20 for Fedora 37.

This separates better the implementation details of the NLL and the
boilerplate code that is necessary to iterate over a set of vector
observables.

By having truly recursive calls to `RooAbsArg::translate()`, one avoids
the need to have an extra `buildLoopBegin()` function for loop
bookkeeping.

This commit adds support for using RooNllVarNew in code-squashing/AD. It
also adds a new test that uses code-squashing and AD based derivatives
to minimize a simple model.

* 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.