Rearrange / rename API reference docs

[HalfWhitt]

Fixes #3941

Changes

• Rearranges the API reference docs as listed in Update categories for Applications, Resources and Other APIs #3941 (comment)
• Also moves the Architecture page from /reference/internals/architecture to /topics/architecture
• Adds redirects for all moves, using mkdocs-redirects
• Excludes snippets from sitemap, using mkdocs-exclude
  • Unfortunately there doesn't seem to be a way of excluding the nav file, SUMMARY.md, without breaking literate-nav and getting just the default auto-generated navigation. It's not a file meant for public consumption, but I don't suppose it does any harm for it to be listed...

I've checked the redirects by downloading the 0.5.3 sitemap and using the following script:

import xml.etree.ElementTree as ET

import httpx
from rich import print

tree = ET.parse("053 sitemap.xml")
root = tree.getroot()

for child in root:
 	path = child[0].text.removeprefix("https://toga.beeware.org/")
 	status = httpx.head(f"http://127.0.0.1:8000/{path}").status_code
 	color = "green" if status == 200 else "red"
 	print(f"{path}: [{color}]{status}[/{color}]")

I also turned on traffic analytics on readthedocs, so I could see what's been getting 404 errors and add those too.

Remaining questions

• Whether Document goes in Resources or Application Components.

• Finalizing the shortened API descriptions, and/or keeping both a long and a short version.

  Now that I've tried it out, I think sticking to one consistent (brief) description is still the way to go; it reads more like the top line of a docstring. This may necessitate reintroducing some of the removed detail at the beginning of the Usage section. I've waited to do this, or to spend much time going over and finalizing shortened versions, before getting feedback on whether the general approach looks good to others.

• How (or if) to visually make the Container Widgets table be visually a subcategory of Widgets.

  I've tried using a lower-level heading:

  

  And even mucking about with a faux-header insert:

  

  I don't think either of these look good or read as intended, and the latter exacerbates how tall the Widgets table already is, requiring even more scrolling up to find the header labels. (Unfortunately, sticky headers doesn't seem to be possible with mkdocs Materials.)

  It's already structurally a subcategory, and reads as such in the sidebar nav. Perhaps that's enough?

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[kattni]

I will take a look this evening.

[kattni]

I somehow failed to click "Finish" in this. I didn't notice until I noticed that my email didn't have a new reply for this PR. 🤦🏻‍♀️

I have one suggestion below. Otherwise, we discussed everything else.

[HalfWhitt]

@kattni @freakboy3742 I think I've covered everything we talked about the other week:

• Rearrange the categories
• Narrow the availability columns to leave more room for the descriptions
• Shorten descriptions wherever possible
• Reintroduce any information removed from descriptions to the Usage section