feat(wip): use wine from extracted appimage

[ctrlaltf24]

removes wine code logic

switches default to using the tarball of the appimage instead to avoid the fuse dependency

• this doesn't yet work inside of distrobox but does work on my debian host. Not pushing yet as there is clearly something I'm not understanding as to how the appimage gets mounted. I'd prefer if this was a pure binary/LD_Library path manipulation rather than having to use the wrapper from the appimage

begins to start writing ci around distrobox

[thw26]

Thinking about this one. One of the benefits of this will be removing issues with AppImages. But the contents of the AppImage will still be unusable by Alpine systems because the Wine inside the AppImage is still not muslc, no?

We will need to acquire a muslc Wine from another source as part of this switch, correct?

[thw26]

Another thought: just cross-linking an issue:

#194

[thw26]

This PR is also necessary for #14

[thw26]

Another note I made: #24 (comment)

What if we aimed for utilizing distrobox in order to simplify our whole process? We could potentially drop some of our dependency installations and rely (solely?) on distrobox.

We could then get around even the muslc (and FreeBSD?) issues by simply utilizing a Debian (or other: Arch to be most up-to-date?) system container.

Not having worked with distrobox, would we be able to prepare a container for distribution even? So instead of maintaining lengthy in-app instructions, could we distribute essentially our own Logos-focused Distro? i.e., maintain a distrobox container repo?

[ctrlaltf24]

If we wanted a cross-distro solution flatpak/snap are more well traveled (and actually known). Regardless of our container solution, we'd still want wine as binaries we build