Documentation updates content + style

[pjbull]

trafficstars

I had a few thoughts while looking at #132 that may be useful for improving our documentation content and styling

Content:

• [ ] "Getting started" page - usually the first page I click on, which should be mostly code and have steps for install, instatiation and simple read/write examples.
• [ ] Examples/cookbook/common use cases (download files, listing dir, globbing, persistent cache)
• [ ] Note about file handles like in this comment
• [ ] Maybe the authentication/caching pages go under an "Advanced" header in the TOC?
• [ ] URI schemes should feature prominently on the homepage/getting started page/methods table, etc. (you have to dig in to find these at the moment)
• [ ] Would be helpful to have some diagrams, especially on the caching page
• [ ] ~~Example usage on the AnyPath page~~ link AnyPath usage page from the AnyPath API reference page.

Style:

• The layout of method signatures can be hard to read. A couple of potential ideas to improve are: (1) remove type hints when laying these out since duplicated below, (2) automatically style these to put each param on a new line, (3) decrease font size, (4)
• Can we strip the In/Out blocks from the notebooks that we use in the docs like we do on the DrivenData blog.

[jayqi]

automatically style these to put each param on a new line

There's an open issue on mkdocstrings requesting this feature.

we strip the In/Out blocks from the notebooks

We could try mknotebooks instead of mkdocs-jupyter. Based on this demo it seems like it doesn't have cell numbers.