Add AUR helper option in Applications menu

[unkver]

I've been using this tool starting from 2023, and I saw myself constantly doing the same thing that takes my time - installing an AUR helper like yay or paru. I thought abt it and I guess a lot of people do that anyways, so here I decided to try contributing to an open source project for the first time.

PR Description:

This adds yay and paru as installable options under the Applications menu in archinstall. And yes, it seems to preview correctly too - under the main menu and under the applications menu.

The way I implemented this is kind of tricky - since makepkg can't be ran as root (and we are root during the archinstall), it makes a service that installs the helper the first time the user boots up their new Arch system, then deletes itself (the service). You can read more in the comments that I wrote.

Tests and Checks

• I have tested the code!

I've tested it a lot in a virtual machine under a lot of circumstances (user picks yay/paru, doesn't pick anything, doesn't make a user), and it works great so far!

It took me a while to understand how this tool works (I took heavy inspiration from the audio option in Applications), and I do understand that there might be a safer way to do this, but this is my attempt to learn and do something useful at the same time :-)

[Softer]

Few technical concerns:

1. Sudoers cleanup is not guaranteed. ExecStartPost runs only if ExecStart succeeds. If the build fails (no network, AUR down, makepkg error, power loss), /etc/sudoers.d/99-aur-helper-tmp stays in place and the user retains permanent NOPASSWD: /usr/bin/pacman. Consider ExecStopPost= for cleanup on any exit, or a trap inside the bash command.

2. Unescaped user.username in the unit file. The username is interpolated directly into the ExecStartPre/ExecStart lines and into the sudoers content. As far as I know archinstall does not currently validate username format in User.parse_arguments, so a malicious config.json could inject unit directives or break the sudoers file.

3. Dangling .wants/ symlink. ExecStartPost=rm -f .../aur-install-{helper}.service removes the unit file but not the enable symlink in multi-user.target.wants/, which systemd will warn about on every boot.

4. Multi-user. Only users[0] receives the helper, silently.

5. It's a dangerous util, so maybe it's better to hide it behind --advanced?

[unkver]

Got it, I guess I'm not good at writing services - will try to fix as soon as possible.
As about --advanced - I can see why, since AUR is maintained by Users, but how about just adding a description (like in the thing in archinstall where you choose if you have a removable drive or not) where it explains that it's not maintained by official Arch packaging people yada yada, and at the end "If you don't know what this means, choose No AUR helper". Because I do think that it's useful to have here as not an advanced feature. If it is - then might as well put UKI and disk encryption behind --advanced. But I just said about the complicated side of things, but if we're talking safety - it's honestly the user's fault, like, you should know what you're installing. And about infected packages - same thing happens with pacman too (xz utill). So I'm honestly up to just putting a description for newbies to explain what these are, but I might be wrong.

[svartkanin]

I would probably argue that this os not essential to get a system up and running and can be considered a post installation step altogether.

Especially as this goes very much into the user space by installing go or rust systemwide. At this point it doesn't fit the "installing a working system" but rather a "setup an installed system".