Fix documentation build and relax sphinx requirements

* Utopia ``ExecPolicy`` mirrors `STL execution policies <https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t>`_.

* Parallel features can be controlled via the :ref:`meta-configuration <feature_meta_config>`.

  The ``PseudoParent`` enables or disables them depending on the ``parallel_execution`` node in the parameter space.

* Depending on the execution policies, programmers will have to avoid `data races <https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races>`_.

* Depending on the execution policies, programmers will have to avoid `data races <https://en.cppreference.com/w/c/language/memory_model>`_.

* 📚

  `Doxygen <../../doxygen/html/group___parallel.html>`__,

  :ref:`Parallel apply_rule <feature_apply_rule>`

Sphinx == 5.*

Sphinx >5.3,<8

# Extensions

sphinx-argparse

.. hint::

    When using the *BoundaryNorm* together with one of the pre-registered colormaps (e.g., *viridis*), use the ``lut`` argument (see :py:func:`matplotlib.cm.get_cmap`) to resample the colormap to have *lut* entries in the lookup table.

    When using the *BoundaryNorm* together with one of the pre-registered colormaps (e.g., *viridis*), use the ``lut`` argument (see :py:func:`~matplotlib.pyplot.get_cmap`) to resample the colormap to have *lut* entries in the lookup table.

    Set ``lut = <BoundaryNorm.ncolors>`` to use the full colormap range.

## Overview

C++17 introduced [execution policies](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) for running STL algorithms in parallel, on multiple threads and/or vectorized instructions.

The decision of executing an algorithm is thereby taken at compile time because this optimizes performance and, depending on the particular policy chosen, poses restrictions on the algorithm and underlying data due to [data races](https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races).

The decision of executing an algorithm is thereby taken at compile time because this optimizes performance and, depending on the particular policy chosen, poses restrictions on the algorithm and underlying data due to [data races](https://en.cppreference.com/w/c/language/memory_model).

However, most large STL libraries still do not support parallel execution policies.

Utopia therefore relies on optional third party software to implement multithreading.

The [Intel oneAPI toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html) is a complete software suite for developing high-performance software on heterogeneous, parallel computer architectures.

The basic rule of thumb is that developers who want their code to be executed in parallel using the Utopia facilities simply write the code as if it was *always* run in parallel, and then replace the STL execution policies with Utopia::ExecPolicy.

In particular, this means that data races have to be avoided, which can be achieved by using [guards against mutual execution](https://en.cppreference.com/w/cpp/thread/mutex) (`mutex`) or [atomic data types](https://en.cppreference.com/w/cpp/atomic) which are inherently safe when accessed by multiple threads simultaneously.

See the notes on [execution policies](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) and [data races](https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races) for additional information.

See the notes on [execution policies](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) and [data races](https://en.cppreference.com/w/c/language/memory_model) for additional information.

Parallel execution at runtime is controlled through Utopia::ParallelExecution and is **disabled** by default.

Utopia::PseudoParent will **disable** parallel execution if the respective parameter space setting is not available.