Automatic deployment of Doxygen documentation

[gflegar]

This PR adds a CI job that automatically deploys Doxygen documentation generated from the latest version of the develop branch whenever develop is updated. The script takes care of the problem of multiple updates that could be caused by the public and private CI systems by creating the job if the PUBLIC_CI_TAG environment variable has been set (which is now true for the public CI system, but not for the private one).

The job uses the ginkgo-bot account to create a new commit on the gh-pages branch in the public repository, which has been set up to host the content of the branch on https://ginkgo-project.github.io/ginkgo/doc/develop/. The public wiki navigation bar has also been updated accordingly.

Note that the job has not yet been set up for the master branch, as we will probably want a different script for that: while we only want to host the newest version of the develop branch, we will most likely want to host documentation for all version of Ginkgo, not just the newest one, so we'll have to figure out which version are we currently building to deduce the correct path for the documentation.

---

Additionally, the PR fixes some problems with the CMake configuration for doxygen builds:

1. Doxygen's PROJECT_NUMBER has been updated to also include the PROJECT_VERSION_TAG CMake variable.
2. Clang-related Doxygen's options have been commented-out, since we do not currently use them, and default Arch Linux's build of Doxygen is not compiled with Clang support, which causes warnings.
3. doxygen_version_extract.sh has been fixed. Now it no longer assumes that the build directory is located inside the source directory.
4. Since doxygen currently produces a lot of warnings (most are false-positives), the doxygen build command has been modified to print all warnings into a log file (doc/usr.log in the build directory). This makes the build output more readable. (However, this should be removed once we have proper doxygen warning filtering set up.)

[tcojean]

LGTM overall. Here are some changes that may be worth considering?

To document functions which are standalone (e.g. gko::transpose), then either:

• the namespace should be documented (gko namespace here)
• the file should be documented
  Source: https://stackoverflow.com/questions/2794054/documenting-functions-in-c-with-doxygen

In addition, if we want to include some functions inside the documentation of a class, such as the operators and transpose for dim, I think the only solution is the following:

• at the beginning of the related function declarations, insert \memberof dim @{
• at the end of the function declarations, close the block /** @} */

Finally, at some point, we may want to also document the master branch separately, do we already prepare a location for that and add master as a target for documentation deployment?

[tcojean]

In addition, the option BUILD_DOC could be added to the README.md.

[tcojean]

There is an option WARN_LOGFILE see doxygen doc maybe that is cleaner than doing it in CMake.

[gflegar]

I've included the comments related to README.md and WARN_LOGFILE. For the other ones I created a new issue #76 since they are more related to how we document the code, than to this particual PR.