The old behavior without a compile_commands.json present in the working
dir was kept available. If this file is present, the new mechanism
will use the actual compiler flags as specified by the build system to
parse the actual file the user is working in and retrieve info about the
token under the user's cursor.

Prelude

Thank you for helping out DoGe!

By contributing to DoGe you agree to the following statements (Replace [ ] with [x] with those you agree with):

• [x ] I have read and understood the Contribution Guidelines.
• [x ] I have read and understood the Code of Conduct.

Why this PR?

In environments where the compiler generates a compile commands database (compile_commands.json). The clang toolchain can use this database to parse files in the exact way the compiler would. This enables reliable identification of the token type for which the user has requested documentation to be generated and associated tokens, such as parameters.
This PR is probably par from perfect, but it improves upon the existing mechanism if a compile commands database is present. The old mechanism for parsing has been preserved.

It should be noted that:

• It is assumed the compile_commands.json file is in the current working dir, as that should commonly be the project root and I didn't feel like searching for it, as that requires quite a bit of heuristics.
• The available token types are limited from DoGe's side.
• The current way of triggering the generator is suboptimal, since it is triggered 3 times, when one pass would be sufficient for the clang-based indexer. This makes documentation generation far slower than it would need to be, resulting in a noticable delay.
• Since header files have no entry inside the compile commands db, clang uses an internal heuristic to guess the correct flags for these files. This can very seldomly lead to incorrect results.