Resolve "Switch to asynchronous mapping for running MC simulations in parallel"

Description

Changes the advanced examples of MC and WL simulations so that Pool.map_async is used rather instead of Pool.map. Also, comments have been added to the corresponding sections of the user guide so that it is made clear that it is strongly recommended to use asynchronus mapping functions.

Summary of changes

• Pool.map has been replaced by Pool.map_async in examples/advanced_topics/parallel_monte_carlo.py as well as examples/advanced_topics/wang_landau/4_run_binned_simulation.py.
• The examples/advanced_topics/mixing_energy.ce, which is used by the former, has been updated since an error is otherwise raised when running examples/advanced_topics/parallel_monte_carlo.py.
• A note has been added to the sections of the user guide that pertains to the parallel MC and WL simulations, respectively, stating that it is recommended to use asynchronus mapping.

To consider

Before submitting your merge request make sure that licenses that might apply to the code that is being submitted are compliant with the license used for this code base. By submitting your code to this repository you also agree that your code will be distributed as part of this code base under the license conditions that apply.

Instructions for code review

Please make sure

• all new code is tested (and works obviously)
• all new code is documented; examples are strongly encouraged
• all new code is type hinted (Note: Type hints are automatically rendered in the documentation when they appear in function/method docstrings; parameter descriptions in class docstrings must be annotated explicitly.)
• variable and function names are in snake_case while class names are in CamelCase
• imports are in alphabetical order both with respect to module names and imported members; core library imports come first in a separate block; import lines go before from lines (This is done to allow other contributors to quickly find imports.)
• all "must-pass" jobs in the CI pass (which includes enforcing flake8 compliance); "can-fail" jobs do not deteriorate
• examples in the documentation use doctest (both sphinx and docstrings)
• code that is commented out should be removed (unless there are very good reasons not to)
• comments that are unclear (e.g., "this should work ..." or "I don't know whether this works ...") need to be resolved first
• todos should be resolved/avoided as much as possible

Closes #508 (closed)