Fixes #7829 finally

Fixes #7829 partially, missing integration into Describe

This fixes issue-7081, as now, with the correct spelling
of the env var, the build-ROOTSYS is picked up by
roottest.

Reactivate the doxygen TOC for \page

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

Std library types are picked up by rootcling as TClasses. If there is no
RField specialization for them, they are passed to the RClassField
constructor. This led to accidental support of those std types by
RNTuple. For some types, this appeared to be benign (e.g. std::pair) but
for others there were errors (e.g. std::optional).

Change the RClassField constructor to throw an exception if any std type
is passed in.

If such mode configured, catch thread id for ProcessEvents
and use that id to process RWebWindow callbacks. Mainly dedicated
for the python, but also can be used in other apps

Indicates that python runs special thread where ProcessEvents called
WebGui has to these ProcessEvents for such calls

Using WebGui.ExternalProcessEvents: yes in rootrc.
In such mode RWebWindow ignores assigned thread id and just executes
functionality in calling thread (which is dangerous)

In this time server will not react on any other user actions,
therefore just block UI with modal message

Means when top folder is shown, one always sees list of files displayed
Therefore when any ROOT file is opened, RBrowser just changes to
its top folder

Provide button to toggle between current directory and list of opened
files

Indicies used for handling many elements with same name in browser,
but do not (yet) supported when configuring working path

ROOT will try to find external version first and
only if fail fallback to builtin variant.

For `std::string`, we have both a TClass and a TDataType (as it is a typedef).
We should prefer the TClass (which fixes issue #7169), but not at the cost
of calling `TClass::GetClass()` first: that is just too slow. So instead,
check for "is it a datatype, not numeric, do we have a TClass?" which will
still prefer the TClass even if *also* a TDataType exists.

Provide documentation!

..rather than building the leaf name "by hand".

If an arena in the MemPoolForRooSets is not referenced anymore, it
should delete the memory it has allocated.

When doing I/O of RVec objects, TClassEdit::STLArgs was accessing
an element one after the end of a static array. asan rightly complains.

This commit fixes https://github.com/root-project/root/issues/7903,
which contains more details.

Deleting a chunk of repeated comment in the description of TH1::GetMean()

Before this patch, given a TTree with a branch with name _different_
from its leaf, e.g. like this:

```
*Br    0 :NUD_total_ADC : nud_total_adc/D
```

RDataFrame only added "branchname.leafname" to the list of available
columns (i.e. "NUD_total_ADC.nud_total_adc" in the example).

In comparison, in a similar situation `TTree::Draw` also accepts
just "NUD_total_ADC" as it assumes that the desired leaf is the
first sub-leaf of the specified branch.

With this patch, RDataFrame also considers "NUD_total_ADC" as a valid
column name as long as it has only one sub-leaf.

This fixes ROOT-9558.

* Port libAfterImage on Win64

Add `libAfterImage/CMakeLists.txt` to facilitate the port of libAfterImage on Win64

* Update CMake minimal version (thanks Oksana)

The distributed RDataFrame constructor accepts an optional `npartitions` keyword argument. Previously, if this argument was provided by the user, it set the number of partitions in which the rdf would split the distributed computations.
But then, right before starting the execution, the distributed backend implementation tried to optimize this number. In the case of Spark, an educated guess for the number of partitions would be spark.executor.cores * spark.executor.instances, that is the number of distributed nodes times the number of cores used for each node.
If we let this optimization happen just before the start of the execution, it means we completely disregard the user provided value for `npartitions`. Instead, the backend guessing at a number of partitions should happen only if the user doesn't supply one.
This commit addresses the issue by moving the call to `backend.optimize_npartitions` inside the initialization of the distributed dataframe object, plus adds a couple of tests to check the behaviour in the Spark backend.