feat: Setting up MkDocs

[internetisaiah]

Overview

Did some research for a static site generator (SSG) that meets the following requirements:

• Free-to-use/open source
• Compatible with GitHub Pages (for free hosting)
• Easy-to-configure
• Built-in global left-side navigation bar
• Built-in global search
• Built-in in-page table of contents
• Built-in ability to create high-level docs sections (like "User Docs" and "Developer Docs")
• Compatible with Doxygen so we can auto-generate the "Developer Docs"

Material for MkDocs seems to be the winner that meets all these criteria. I put together this PR with a preview (although there's still some work to do).

Viewing the site locally

To view the docs preview locally, run the following commands:

pip install mkdocs-material
git checkout setting-up-mkdocs
mkdocs serve

Your terminal output will be similar to the following:

➜  lampray-docs git:(setting-up-mkdocs) mkdocs serve                        
INFO    -  Building documentation...
INFO    -  Cleaning site directory
INFO    -  Documentation built in 0.18 seconds
INFO    -  [21:59:33] Watching paths for changes: 'docs', 'mkdocs.yml'
INFO    -  [21:59:33] Serving on http://127.0.0.1:8000/
INFO    -  [21:59:34] Browser connected: http://127.0.0.1:8000/
...

Here's what you should see in your web browser:

Next steps:

• [ ] Continue to edit/cleanup the current docs.
• [x] Add site logo
• [x] Add Code of Conduct
• [ ] Adjust color scheme using custom colors.
• [ ] Configure a GitHub action to deploy the docs to a free GitHub pages site. (Walk-through here).

[internetisaiah]

@CHollingworth @SnazzyPanda , working on setting up a static site generate for us. See PR description above for more info and let me know your thoughts so far. Still a bit more to do, but wanted to let you see the progress so far.

---

Also, some suggestions for the repository. Feel free to ignore these, as CH is still the project lead, so they get to make the call:

• Change "PR title" requirements to use title or sentence case with full spelling. For example, change feat: to Feature:.
  • Personally, I would remove this requirement entirely and instead use dedicated GitHub tags. I think using tags is better because this info can be queried using the GitHub API, whereas partial strings from a title cannot. See API reference docs: Get a pull request and Git tags.
• Allow contributors to add a reviewers themselves.
  • You can make this more streamlined by creating one or two review teams like @code-reviewers and @docs-reviewers so the respective people are notified. This way different Lampray admins/high-level contributors are tagged depending on the review type.