Add cmake doxygen target and remove unused files

[PhilipFackler]

Description

Add a doxygen target (make GridKitDocs) to CMake

Proposed changes

Use CMake's FindDoxygen module to create a doxygen target with custom options set in docs/CMakeLists.txt. This makes maintenance easier since we only customize a handful of options.

NOTE: I removed the top-level Doxyfile and mainpage.dox because it seemed like they weren't actually used for anything.

Checklist

• [N/A] All tests pass.
• [N/A] Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• [N/A] The new code follows GridKit™ style guidelines.
• [N/A] There are unit tests for the new code.
• [N/A] The new code is documented.
• The feature branch is rebased with respect to the target branch.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

[nkoukpaizan]

Looks good to me. I was able to build the target locally (make GridKitDocs) and look at the documentation.

Some things need fixing in the documented code, but that's out of scope for this PR.

@PhilipFackler could you elaborate on why this is a superior approach? Perhaps a README file in docs/ could document this and provide instructions for building?

[pelesh]

NOTE: I removed the top-level Doxyfile and mainpage.dox because it seemed like they weren't actually used for anything.

The Doxyfile could be used to specify Doxygen options instead of specifying them in CMake wrappers for Doxygen options. File mainpage.dox should stay there because we would eventually like to create a nice landing page for the documentation.

[PhilipFackler]

could you elaborate on why this is a superior approach?

I'm not 100% sure I understand the question, but here are my thoughts:

1. I find it easier to maintain just the options I customize rather than a whole Doxyfile (leave what can be generated out of the repo). And if I ever need to customize another option, it's easy to look it up.
2. It makes sense intuitively (to me) for it to be a "product" or "artifact" of the code, and therefore a buildable "target"
3. I prefer generated files not be placed in the source directory. The binary directory makes sense for this, and the CMake target makes this easy.

I get that this is partly a matter of preference.

[nkoukpaizan]

could you elaborate on why this is a superior approach?

I'm not 100% sure I understand the question, but here are my thoughts:

1. I find it easier to maintain just the options I customize rather than a whole Doxyfile (leave what can be generated out of the repo). And if I ever need to customize another option, it's easy to look it up.
2. It makes sense intuitively (to me) for it to be a "product" or "artifact" of the code, and therefore a buildable "target"
3. I prefer generated files not be placed in the source directory. The binary directory makes sense for this, and the CMake target makes this easy.

I get that this is partly a matter of preference.

Yes, that answers my question. I want us to keep a record of these choices.

Also, the reason I'm asking to document the build is that doxygen_add_docs excludes the target from default builds by design, and we want (new) developers to understand how this works. These could even be comments in the docs/CMakeLists.txt.

[PhilipFackler]

@nkoukpaizan I added docs/README.md. Let me know what you think (or feel free to add/change as you like).