* Remove INCLUDE mod file generation in tests

- include mod files generation cause race condition with parallel tests, see BlueBrain/nmodl#1290
- the included files are trivial examples for testing and they don't need to be
  generated from the code
  - could be copied via configure_file
  - cmake could generate those at a configure time

Considering the use case and it's triviality, I thought 2nd option is better. That
also allows to remove some extra code/logic.

NMODL Repo SHA: BlueBrain/nmodl@844e6bd

---------

Co-authored-by: Nicolas Cornu <nicolas.cornu@epfl.ch>

NMODL Repo SHA: BlueBrain/nmodl@751377d

NMODL Repo SHA: BlueBrain/nmodl@3754a71

The new structure is to have one directory per keyword. Tests can be organized in separate test files, named test_*.py (or simulate.py if that's a better name).

Numerous tests have been polished to make them easier to read, using better names and functions to extract common functionality.

NMODL Repo SHA: BlueBrain/nmodl@cc44ecb

NMODL Repo SHA: BlueBrain/nmodl@56b507c

The executable from the Python library.

NMODL Repo SHA: BlueBrain/nmodl@c5ecfea

The changes are:

* Don't forcefully set the PYTHONPATH.
* Replace false object oriented code with a function (each).
* Replace a global variable, with a function to initialize.
* Use a reference for a pointer that's should never be a nullptr.



NMODL Repo SHA: BlueBrain/nmodl@2636b4e

Frequently `_lmr` is passed by pointer, which requires printing:
```
  foo(&_lmr, ...);
```
the `&` is annoying, because it prevents us from using `get_arg_str`. It
also sometimes leads us to do:
```
  auto * _ml = &_lmr;
```
which is bad, because it's not a `Memb_list`.

* Rename '_lmr' to '_lmc'.

NMODL Repo SHA: BlueBrain/nmodl@13550d7

NMODL Repo SHA: BlueBrain/nmodl@9562893

NMODL Repo SHA: BlueBrain/nmodl@8679d7e

There must not be a clash of FUNCTION and RANGE names.

NMODL Repo SHA: BlueBrain/nmodl@d226bef

NMODL Repo SHA: BlueBrain/nmodl@fd2cd16

NMODL Repo SHA: BlueBrain/nmodl@e5964fe

NMODL Repo SHA: BlueBrain/nmodl@64cf627

NMODL Repo SHA: BlueBrain/nmodl@635b31f

These are global variables, and when THREAD_SAFE act like thread
variables, without being exposed to HOC/Python.

NMODL Repo SHA: BlueBrain/nmodl@e9e127a

NMODL Repo SHA: BlueBrain/nmodl@a7bf7d9

NMODL Repo SHA: BlueBrain/nmodl@bf67f44

NMODL Repo SHA: BlueBrain/nmodl@5ff221d

NMODL Repo SHA: BlueBrain/nmodl@de8e623

NMODL Repo SHA: BlueBrain/nmodl@c8d0833

NMODL Repo SHA: BlueBrain/nmodl@7beaee9

NMODL Repo SHA: BlueBrain/nmodl@ef3ec39

Similar to BlueBrain/nmodl#1305, include the solver headers in variables in a C++
header, and include them in the code generated for the MOD files. This
should allow to substitute different NMODL binaries in NEURON builds
without confusion as to which solver headers are going to be included in
the MOD file compilation.

NMODL Repo SHA: BlueBrain/nmodl@7910146

NMODL Repo SHA: BlueBrain/nmodl@a209d0a

Solving non-linear system causes a function object to be present in the
generated code. This function object was missing the required code to
handle thread-variables.

NMODL Repo SHA: BlueBrain/nmodl@87e11cb

NMODL Repo SHA: BlueBrain/nmodl@332c8b3

* Implement printing for CONSTANT.

* Document CONSTANT.

* Register `constant` usecase group.

NMODL Repo SHA: BlueBrain/nmodl@6be1a19

* Add regression test.

* Don't print `int*` range variables.

NMODL Repo SHA: BlueBrain/nmodl@2af37ab

…nmodl-merge-cmake