Arronax entrypoint assumes it will be called with `sys.argv[0]` contained in the directory where the entrypoint resides.

[Adriano Zambrana Marchetti]

Executing `python setup.py install` in some cases (an installation in Arch Linux, for example), create a script at `/sbin/arronax`, which is what is first executed, and then call the main entrypoint with `/sbin/arronax` as `sys.argv[0]`, while all the other arronax files (ui files, other python files, etc) reside in `/usr/share/arronax`.

The `settings.py` file calculates this DATA_DIR based on `sys.argv[0]` (Line 57), resulting in `editor.py` trying to load `/share/arronax/ui/edit.ui`(Line 129) instead of `/usr/share/arronax/ui/edit.ui`, crashing the program, and the following traceback:

```
Traceback (most recent call last):
  File "/sbin/arronax", line 33, in <module>
    sys.exit(load_entry_point('arronax==0.8.1', 'console_scripts', 'arronax')())
  File "/usr/lib/python3.10/site-packages/arronax/editor.py", line 726, in main
    editor = Editor(args.path, args.stype, args.dir)
  File "/usr/lib/python3.10/site-packages/arronax/editor.py", line 44, in __init__
    self.create_builder()
  File "/usr/lib/python3.10/site-packages/arronax/editor.py", line 129, in create_builder
    self.builder.add_from_file(os.path.join(settings.UI_DIR,
gi.repository.GLib.GError: g-file-error-quark: Failed to open file “/share/arronax/ui/edit.ui”: No such file or directory (4)
```

I've attempted hardcoding `sys.argv[0]` to `/usr/share/arronax` within the `/sbin/arronax` script, which results in correct behavior, however, this code is generated by setuptools, so should ideally not be modified. Attached is a copy of this script.

This was discovered on the comment section of the AUR package which bundles this program for Arch Linux. This is the URL of the comment section: https://aur.archlinux.org/packages/arronax/#comment-847832

Update: I've found the root source of the bug

Under some systems,including Arch, `/sbin` is a symlink to `/usr/bin`, which means that this program, when installed, can be called from multiple locations. The fix is simply to resolve the real path of the executable before traversing directories to find the DATA_DIR.

I've packaged a solution as a git patch that can be applied to the current main branch.

[Adriano Zambrana Marchetti (azmcode)]

Essentially changes a single line, removing the unnecessary `os.abspath` call, and wrapping the inner `sys.argv[0]` in a `os.path.realpath` call.