Add topic stubs to Synapse Docs

[H-Shay]

@anoadragon453 and I were discussing how to improve Synapse's developer documentation and we came up with an outline of topics that we would like to see added to the docs. This PR adds those topic stubs to the table of contents, with the hope that the team and contributors alike will then help fill in the stubs and improve the documentation going forwards.

[anoadragon453]

Thanks for turning this into a PR Shay!

I would be interested in other's opinions on the topics of the docs laid out here.

[anoadragon453]

Others should note that the non-markdown links have no effect in SUMMARY.md, and are instead presented here as ideas for headings in pages / general notes.

They are left to give one an idea of what a page may contain, and will be removed/transferred to the parent doc pages before this PR merges.

[MadLittleMods]

I like this section 👍

Some copy-pastable snippets on how to explore the database would also be nice (cheat sheet):

• psql synapse: Open the postgres CLI against the synapse database
• \q -> enter: To quit/exit
• \dt: list tables
• \d+ issues: list columns and indexes for issues table
• CREATE TABLE board_labels();: Create a table called board_labels
• DROP TABLE insertion_event_extremeties
• explain SELECT * FROM events WHERE depth = 1;
• explain analyze SELECT * FROM events WHERE depth = 1;

-- #10245

[MadLittleMods]

👍 Definitely interested in how to work with and use all of the jaeger stuff!

[clokep]

@H-Shay, @anoadragon453 Do you think we should land this or close it?

[H-Shay]

Fair question, I am interested in landing something like this, even if it doesn't go in the developer documentation (I think there were concerns with it becoming overwhelming?). Let's close this for now and maybe I'll flesh out something that could go in contrib or stand on it's own as an overview of Synapse.

[anoadragon453]

In our Internal Backend Chapter sync, we talked about instead documenting these items as long-form docstrings in the code base. I think this PR served as a good place to drum up ideas of things to document. We could now take it as inspiration for documentation to write alongside the code. For instance, if we want to write about Background Jobs, we should add to the docstring of the _BackgroundProcess class. File headers can have descriptions of the whole file, as well as general topics that cover multiple classes.

I think our current documentation suffers from us not looking at it frequently enough. Whereas if it were more intermixed with the code then we'd come across and update it more frequently.