Navigating errors when producing PDFs in ARM Linux containers

I spent a few hours wrangling PDF issues on linux-arm64 (Docker devcontainer on macOS). Ultimately, I did get it to work, and here's what I found.

1. The quarto install tinytex platform error does not provide any direction other than installing manually. A link to https://yihui.org/tinytex/#installation would be helpful here.
2. Freshly installed, quarto needs to retrieve multiple packages on first run, and that retrieval fails more often than not (up to six retries needed in my experience). Those error messages about database versions aren't all that helpful, when retrying repeatedly is the fix.
3. For automation, it seems better to use Texlive from package repositories, because it very consistently works and avoids the tlmgr updates that cause the problem above. However, be aware of the issue below.

From #909:

xelatex is indeed the default (but also I believe comes with all versions of tinytex and all downloads of texlive so isn't normally something that should require dynamic download).

This is not the case for Debian packages, and a lot of containers are Debian images. When using a Debian Texlive install, quarto produces a badly misleading error about updating Texlive, which ends up being wasted time, because xelatex missing is the real problem.

This works on Debian:

sudo apt-get update
sudo apt-get install texlive texlive-xetex

Suggestions:

1. (Workaround) Add the install link to the platform error.
2. (Workaround) It's probably more of a Tinytex issue, but handle retries for package installation to overcome the unreliability.
3. (Best fix) Package Tinytex for arm64. https://github.com/rstudio/tinytex-releases/issues/37
4. (Also) Handle the case of missing xelatex better, particularly by not suggesting Texlive upgrades in cases where it's not the problem.

### Tasks
- [ ] https://github.com/quarto-dev/quarto-cli/issues/7681
- [x] Add the install link to the platform error.