Add flyctl to the default software registry

[phenaproxima]

Adds flyctl to the default software registry, as requested in #139.

Notes on the entry:

• Asset pattern /^flyctl_.*/ matches the release assets (flyctl_0.4.115_macOS_arm64.tar.gz, etc.); the asset selection rules already exclude the _checksums.txt file.
• Binary pattern /^flyctl(?:\\.exe)?$/ matches exactly the binary: the tarballs contain a lone flyctl, and the Windows zip contains flyctl.exe plus a wintun.dll helper that must not match.
• Binary name is fly, not flyctl: dload renames the extracted binary to the configured name (keeping the real extension), so it lands as fly / fly.exe — matching the command name used throughout the fly.io docs. This also makes dload's existence checks and PATH lookups find a globally installed fly.

Closes #139

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

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

[roxblnfk]

@phenaproxima a question about the binary name: the entry installs the executable as fly, while the archive ships flyctl and the software alias is flyctl too. Was the rename intentional?

I see the Fly docs use fly as the main command, but their installer also keeps flyctl, and a lot of CI examples call flyctl deploy. Someone who adds <download software="flyctl"/> would probably expect ./flyctl to exist. Would keeping flyctl as binary.name work for your use case, or do you rely on fly?

[phenaproxima]

I don't feel particularly strongly about it; flyctl would be fine. The reason I changed it to fly was to match fly.io's documentation, which refers to the utility as fly every time. So that was just an attempt to avoid confusion.