Set up Read The Docs (RTD) Scaffolding and Sketch Docs Website

[jhiemstrawisc]

This sets up some of the basics the SPRAS team has discussed w.r.t. building an official documentation website. I tried to focus on organization/scaffolding for the docs, and not so much the content (which I'm less qualified to write).

I also spent some time putting together some meta docs to explain to others how to write/build/visualize any documentation changes they may choose to make. My hope is that I can help the group with formatting, structure, and hosting, and others can work on the biology

While the changes in this PR function to generate documentation, this doesn't yet address the actual hosting of any documentation, which is outside the scope of what I can accomplish in a PR because it requires RTD account creation and the generation of github secrets.

Here's a screenshot of the landing page these changes currently produce:

[jhiemstrawisc]

A few questions I have at this point:

1. What should we do about the existing doc/ folder, that holds a few markdown files and an image that's linked into the root README? It'll be confusing to have both a doc/ and a docs/ folder, but the contents of doc/ really don't belong in docs/ because they're not built into the website.
2. Funny enough, we already had a lot of the sphinx and read the docs dependencies baked into our pyproject.toml and environment.yml. I suspect these really aren't dependencies unless you're planning to work on documentation. Does anyone foresee any issues moving these into the "optional" sections of those dependency declarations?

[agitter]

The initially structure looks really great. I understand most of the pieces but not necessarily how every single file fits together.

What should we do about the existing doc/ folder

I believe we can convert all the markdown files there into something that would be part of the SPRAS docs. Would that involve converting to rst?

[agitter]

I actually dislike line wrapped markdown. The preference comes from our Manubot project for writing collaborative manuscripts with markdown, where we recommend one sentence per line. I would be okay enforcing that with a hook.

[agitter]

Suggested change

	based on the contents of the `docs/` file in this repository by periodically
	based on the contents of the `docs/` directory in this repository by periodically

[agitter]

Suggested change

	popular python python package that tries to make documentation easy to write,
	popular python package that tries to make documentation easy to write,

[agitter]

Suggested change

	a ToC.
	a table of contents.

[agitter]

Is this going to be committed? The text below suggests no, should should we remove the link? We already ignore it.

[agitter]

I'd like to avoid the PRM algorithm in the docs. We could call these "Algorithms" generically if space is limited or "Network Algorithims" if we have a little more space.

@annaritz what do you think?

[agitter]

We'll have to add these for each new module manually?

[agitter]

Can we link this to the auto-generated API documentation for the module?

[agitter]

This is another area where we'll need to update the contribution guide if the list of algorithms needs to be extended manually.

[agitter]

I believe the sphinx dependencies came from graphspace. That is currently a required packaged for one of our pathway output file formats, so all of its dependencies may also be required.