Add ezgl Doxygen api documentation to to the VTR docs

[SamuelHo10]

Integrated EZGL’s Doxygen documentation into the VTR ReadTheDocs site under a new "EZGL" tab in the vtrutil API section.

The header files containing only functions and no classes did not generate documentation correctly when I used
.. doxygenfile:: control.hpp
:project: ezgl

I am not sure why, but adding the functions manually in worked:
.. doxygenfunction:: ezgl::zoom_in(canvas*, double)
:project: ezgl

[vaughnbetz]

Thanks @SamuelHo10 !

[vaughnbetz]

This looks good and I'm merging it, but I have one suggestion:

• Either in Doxygen comments in the code that will show up at the top of ezgl.rst, or in the ezgl.rst file itself, I think you should add a short overview of ezgl. Here's some potential text:
  EZGL is a graphics layer on top of version 3.x of the GTK graphics library. It allows drawing in an arbitrary 2D world coordinate space (instead of in pixel coordinates), handles panning and zooming automatically, and provides easy-to-use functions for common tasks like setting up a window, setting graphics attributes (like colour and line style) and drawing primitives (like lines and polygons). Most of VPR's drawing is performed in ezgl, and GTK functionality not exposed by ezgl can still be accessed by directly calling the relevant gtk functions.

[soheilshahrouz]

Thanks @SamuelHo10

A couple of suggestions:

1. The new page is added under the vtrutil library, but ezgl isn't part of vtrutil, which might be confusing.
2. Instead of having several .rst files, it might be clearer to combine them into one. This would make the file structure easier to follow.

[vaughnbetz]

@soheilshahrouz : good point on libvtrutil. I suggested putting ezgl under vtrutil (thinking of it as a utility) but you are right it is not part of the library we build for utilities so probably it would be better to make it another top level category; we could move it between vtrutil API and vtr internals

[AmirhosseinPoolad]

Another suggestion @SamuelHo10, I think you should squash the commits for this PR into a single commit with a descriptive commit message. While it doesn't really matter that much for a documentation change, it's good practice to have atomic commits i.e. commits that take the code from one working state to another and do/add one thing to the code nonetheless.

You can look here to see how squashing and some other useful git tools work:
https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history

Also if you use the GitLens extension for VSCode it gives you a nice UI which might be easier to work with. Just make that when you run git rebase -i HEAD~n, n is the number of commits you have in your branch and not more than that. If you do HEAD~1000 it would mess with the git history.

Sorry to give you extra work!