Add Documenter docs and docstrings

[emstoudenmire]

This PR adds docstrings to many user-facing functions and create a Documenter setup plus additional Documenter content.

All content (docstrings and Documenter pages) have been manually checked, and I ran and tested the example codes appearing in the Documenter. I created a file test/test_documentation_examples.jl for this purpose.

One question is whether there should be a whole page on the TreeTensorNetwork type, or whether we should somewhat de-emphasize that type. I think it might be better to leave it clearer for someone who is trying to understand the structure of the code and who might occasionally see issues where one needs to convert to the ITensorNetwork type, and so must appreciate that it is a different type.

[mtfishman]

All content (docstrings and Documenter pages) have been manually checked, and I ran and tested the example codes appearing in the Documenter. I created a file test/test_documentation_examples.jl for this purpose.

It would be nice to set it up so that examples interspersed in the docs are run during CI and we get some indication that they at least run without erroring. I think the minimal change to make to achieve that would be to change over the julia codeblocks to @example codeblocks (https://documenter.juliadocs.org/stable/man/syntax/#reference-at-example) which get run by Documenter when the docs are built. Then, if we remove warnonly = true from makedocs in docs/make.jl, if the examples don't run the docs build will fail so we know to look into the examples as a potential issue. test/test_documentation_examples.jl isn't really a sustainable solution since that would need to be updated as the docs are updated, which isn't very practical and that process itself would be error-prone.

(Note that you can do fancier things where you turn them into proper tests where you check the output: https://documenter.juliadocs.org/stable/man/doctests but we don't have to do that here, just pointing it out for future reference.)

One question is whether there should be a whole page on the TreeTensorNetwork type, or whether we should somewhat de-emphasize that type. I think it might be better to leave it clearer for someone who is trying to understand the structure of the code and who might occasionally see issues where one needs to convert to the ITensorNetwork type, and so must appreciate that it is a different type.

Since it plays an important role in the existing form of the library it seems reasonable to document it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.43%. Comparing base (4e59ab2) to head (0ea5a8e).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #300      +/-   ##
==========================================
+ Coverage   69.07%   71.43%   +2.35%     
==========================================
  Files          81       81              
  Lines        4029     4029              
==========================================
+ Hits         2783     2878      +95     
+ Misses       1246     1151      -95     

Flag	Coverage Δ
docs	36.49% <ø> (+36.49%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mtfishman]

@emstoudenmire I changed over most docstrings to regular comments so the API Reference list is much smaller. We can add them back as needed.

[mtfishman]

@emstoudenmire I went ahead and finished the final comments (mostly because I want to get things off my to-do list and didn't want to forget about this PR).

[emstoudenmire]

Thanks for resolving those comments & pushing this ahead. Will be great to have the docs!