Fix Missing highest variant + new file format upstream

[JessicaTegner]

Fixes #43.

Problem

rstudio/tinytex-releases changed its asset naming in v2026.04. Variants TinyTeX-0 and TinyTeX-1 now ship only as
.tar.xz (macOS/Linux) and .exe (Windows, 7-Zip self-extracting archive). The old .zip / .tgz / .tar.gz files are gone
for those bundles, so download_tinytex() with the default variation=1 on latest found no assets and failed on every
platform, not just Linux ARM.

Separately, as reported in #43, variation=2 mapped to the community TinyTeX bundle rather than TinyTeX-2.

Changes

• Variation numbers now match the release names: 0 → TinyTeX-0, 1 → TinyTeX-1 (default), None → TinyTeX (community
  bundle), 2 → TinyTeX-2 (full TeX Live).
• version="daily" is accepted. variation=2 only exists in the daily release, so variation=2 with version="latest"
  switches to daily automatically; combining it with a pinned version raises a clear error.
• New asset selection (_select_tinytex_urls): one regex handles both the old naming (TinyTeX-0[-arm64]-v2026.03.tar.gz
  / .tgz / .zip) and the new naming (TinyTeX-0-linux-arm64-v2026.08.tar.xz, TinyTeX-0-windows-v2026.08.exe). Legacy
  archives are preferred when both exist. Linux ARM picks the linux-arm64 asset.
• Extraction: tarfile opened with "r:*" (gzip and xz), Windows .exe extracted with -y -o (same as R's
  tinytex::install_tinytex()), extracted folder located by name (TinyTeX / .TinyTeX) instead of guessing from the file
  extension.
• CLI: --variation {0,1,2,none}, --version help mentions daily.
• README, test cleanup and .gitignore updated for .tar.xz / .exe.

Breaking change

variation=2 now means TinyTeX-2 (scheme-full, ~1.7 GB, daily only). Anyone who used variation=2 for the community
bundle should pass variation=None instead.

[IvanaGyro]

I also checked with a GitHub workflow on my forked repo. It successfully downloaded and installed corresponding variants. However, there is a point that can be improved. This PR can parse the filename/link for musl Linux, but it doesn't download musl variant for it.

[JessicaTegner]

@IvanaGyro Good catch, thanks for testing on your fork. Added: on musl-based Linux (detected via /lib/ld-musl-*.so.1) the linuxmusl-x86_64 asset is now picked. Falls back to the glibc build where upstream has no musl asset (releases before 2026.04, and arm64). Covered by test_select_urls_musl.
Please do test again, if you would be so inclined. Of you don't have a way, feel free to just take a look at the code to see if this fits what you raised.

[IvanaGyro]

musl workflow works for x64, but not arm. Usually, musl system cannot run glibc build, so the fallback is usually wrong and give musl arm users wrong error messages. Maybe just raise an error when prebuilt package is not supported instead of fallback to glibc.

Additionally, I wonder why the packages are unpacked to a temporary folder and then copy to the destination? Copying a lot of small files cost a lost of time. Will we consider to directly unpack to the destination or use move instead of copy?