Add docgen sub-package

[goerz]

We have long planned to replace the Perl scripts that are still being used as part of QDYN's build process with equivalent Python scripts (to simplify everything down to a single "support" language that a majority of students can develop in). The most significant part of this is the Perl script that generates the documentation.

In this context, we would benefit moving the documentation from our custom generator to Sphinx. Apart from being visually more appealing, we would gain the ability to use the reRestructuredText (RST) markup language. RST, being specifically designed for software documentation, would be significantly more expressive than our current custom markdown dialect, especially with regards to internal and external references. Through intersphinx, we would be able to link to routines from QDYN to qdynpylib and vice versa (as well as any other package using Sphinx for documentation, krotov, qutip, weylchamber,...).

The way to implement this would be to write a Python script (as an entry point to a routine in a new module qdyn.docgen) that takes a Fortran module file (any *.f90/*.F90 in QDYN) and generates an RST file using the Fortran Sphinx Domain. The result would look like shown in SphinxFortran's example. Note that SphinxFortran contains an "autodoc" feature that tries to do something similar as what we want to achieve, but based on its own conventions for Fortran docstrings and comments. In theory, we could fork SphinxFortran and modify it to work based on QDYN's docstrings convention, but I think it will be much easier to just write our own processor that simply converts Fortran modules into RST files.

As an implementation detail: it is probably best to parse each Fortran module entirely into a data structure (nested list/dict) containing all the variables/subroutines/parameters/etc. and their docstrings, and then to generate the RST from that. This is what the current docgen.pl script does as well. Such a data structure could be used beyond just generating the documentation, e.g., for creating dependency graphs of which modules depend on which other modules, scripts for refactoring code, or some one-off semi-automatic conversion of the docstrings from our Markdown dialect to the RST format. For the long-form parts of the documentation, pandoc can automatically convert between markdown and RST.