fix: Replace incorrectly used Systemd Alias directive with a WantedBy

[irvingpop]

Which problem is this PR solving?

In testing Refinery with Amazon Linux 2023, I noticed that systemd refused to start the Refinery service, complaining about:

Failed to enable unit: Cannot alias refinery.service as refinery.

I asked the Amazon Linux devs what they thought about this, and they pointed out that Alias directive is being used incorrectly and helpfully suggested a better replacement. Their comment:

I'm a bit surprised this ever worked, actually. At best it was redundant, but it's not clear that it was ever even valid. Going back as far as AL2's systemd 219, the documentation indicates that aliases must specify the same suffix as the original unit file. An alias without a suffix at all has never been documented as being valid or meaningful, and systemd commands like systemctl would automatically apply a .service suffix to unqualified arguments (so, e.g. even in AL2, systemctl status sshd was equivalent to systemctl status sshd.service with no explicit aliases involved.)

A usual [Install] section does not normally need to specify an Alias= directive at all. Most likely the only line you'll need there is a WantedBy= directive indicating the services or targets that trigger the activation of this service. WantedBy=multi-user.target is a good place to start.

Short description of the changes

This PR updates our Systemd unit file, replacing the Alias directive (incorrectly used, expected to break on other newer systemd-using OSes) with more of a "best practices" kind of line ( WantedBy=multi-user.target )

[kentquirk]

Honestly, I didn't know what this file did. Thank you.