Depending on the TBB version found, we now use task_arena if
available, or else, task_scheduler_init. This patch has the
necessary changes to FindTBB.cmake and the CMakeLists.txt of
the ParUtils library.

regularize, extract_props and multi_hist_cv can again use
-threads option with TBB versions providing task_arena as well
as older versions only providing task_scheduler_init.

Here we restore the -threads option for simulation programs
like ParTempRun for recent TBB versions without task_scheduler_init.
Like in the V210 branch, we use tbb::task_arena. But for V200, we
want to preserve compatibility with older (pre-oneapi) versions
of TBB. When such a TBB version is used, CMake has to find the old
tbb::task_scheduler_init, and set up some compile definitions,
like PRF_USE_TASK_SCHEDULER_INIT. The source files now check
this macro to decide between task_scheduler_init and task_arena.
Since these two ways to set up the number of workers differs in
some significant ways, we end up with a some ugly pre-processor
macros in the simulation programs.

Recent versions of TBB (with OneAPI) have a header tbb/version.h
with API version information. In older TBB versions we had a different
header "tbb_stddef.h". ProFASi FindTBB.cmake looked for that older
file. We could check for tbb/version.h, but that runs into complications
that the file often has a single #include line including oneapi/version.h.
This negates a simple filename switch. We therefore remove any checks
based on tbb_stddef.h, so that ProFASi can compile when the version is
recent enough. We lose descriptive error messages when the API version
is too old though.

Some recent versions of tbb do not have tbb::task_scheduler_init.
The current development branch of ProFASi uses the task arena to
set up the tbb executor. Version 2.0 of ProFASi still used the
task_scheduler_init for this purpose, and worked with older
TBB versions. In order to maintain compatibility with versions
of TBB with and without the task_scheduler_init, we make some
features depend on the existence of task_scheduler_init. ProFASi
will build and run fine without it, but some options, such as
setting the thread count through command line options will not
work. It would be possible to change this branch to task arena,
but we will try to avoid doing so for this retiring branch.

When both comparison structures in RMSD come from the simulation,
the RMSD value returned was incorrect, as it was still calculated
on the assumption of fixedness of the first structure. Properties
of the first structure such as radius of gyration, used in the
RMSD calculation were calculated and stored at initialisation were
used throughout, even when the first structure was not a fixed
one from a PDB file.

The lines in the description of argparse are wrapped by default.
Since we want to use the formatted doc string, we have to add
`formatter_class=argparse.RawDescriptionHelpFormatter` as argument.

update_g, when called from ctest does not have an environment
where other programs like "prf", "mc_stats" are in PATH. It
therefore needs a special PATH set up for the subprocesses it
spawns.

Live generation of gpars.out was broken, as pointed out by Stefan
Wallin. The monte carlo statistics, such as visit counts to different
temperatures are now calculated in bunches, and the counters are
reset regularly. SimTempRun did not take that into account, and
hence generated g_T = 0 for all T randomly in the middle of a
run. The values in the file gpars.out were therefore completely
wrong eversince the statistics collection method was changed.
With this patch, we simply remove the live generation of gpars.out
file, and move that action to a post processing step. The user
is now supposed to run "prf simtemp update_g" after a simulated
tempering run to generate a new g parameters file, and replace
the gpars.in file consciously. There is more flexibility now,
as we can choose how much of the previous run should be used to
re-calculate the g-parameters after the run is finished and we
have inspected the "rt" files. For instance, to use cycles
starting from 200000 in the calculation of new g-parameters, we
can now do this "prf simtemp update_g --starting_cycle 200000".
See "prf simtemp update_g --help" for details.

It is possible to request xml output with -xml. It is possible to
pick a specific child node in the information tree with a -get
option, similar to how prfxml handles that option.

SimTemp will now write the g-parameters in the binary configuration
files, so that the parameters used in the simulation will always
be available for inspection along with the binary data. The
values will be visible using the runinfo system : "prf runinfo -m"

If we try to open a normal file with JoinedTextFileIstream,
it should emit an error, because all read operations will fail.
For now, non-existent files are handled separately.

We expand the "prf" script interface to add a few scripts to
manage simulated tempering runs. Eventually, there should be
some setup scripts, and may be simulated tempering specific
post-processing scripts here. For now, we have only the cover
script "prf simtemp" and "prf simtemp update_g". The later
calculates new g-parameters from input g-parameters and the
visit counts to different temperatures collected from a run.
This will now be the "official" way to update g-parameters.
The parameters as generated during a run are no longer correct
as they only take the visit counts in the latest "packet" in
the monte carlo statistics. The live generation of gpars.out
will be removed.

The user documentation that was included in the source code of the
corresponding classes was moved to reStructuredText files in the doc
directory. It is now available again when documentation is build, but
some cleanup is still needed.

Incremental update does not access elements of a zero sized
array anymore ObsExpression initializes its internal copy of
the incremental update. Observable gets new functions to
getPopulation(), as that can be used to selectively and
lazily initialize some.

When a new FF term is added after the force field
has been fully set up, the newly added term must be
given a population and initialized.

While harvesting possible disulphide bond sites, Seq(i) was previously
compared with C. For proteins with an N-terminal ligand,
Seq(i) would be offset by 1 compared to the index needed
for accessing the i'th amino acid. It's better to compare
AA(j)->OLC() with C. We also extend the search for the
participating Sulfur atom to both the labels " SG " and
"_SG_".

Some vestigial warning messages about the total number
of moved atoms and apparent misplacement of atoms discovered
during update_cells() were silenced.

A typo broke the message about the atoms involved in a disulphide bond,
writing out the id of the first atom twice. A logical operator, which
should have been "and" was mistakenly written as "or".

In prf::Wrap, because of copy-and-paste, post-increment and
post-decrement operators were incorrectly returning references,
leading to dangling references and SEGFAULTS.

GroupLibXML represents an XML node containing information about
entities available for simulation, presumably provided by the
force field class.