Move packaging to containers for cross-packaging

[provokateurin]

Split of #30 (exactly: #30 (comment)).
Moves packaging to containers for packaging to work on all OSs. Requires Docker to be installed.

[GeertJohan]

Nice, I like the refactoring, code separated into specific files and packages etc.

Is it possible to keep docker optional when targetOS == runtime.GOOS? Then users don't have to install docker if they already have (e.g.) snap installed.
On the other hand, this creates situations where different approaches are used based on OS, more code to maintain...

@Drakirus thoughts?

edit: I haven't done a complete code-review of this PR yet

[pchampio]

I'll also prefer to keep Docker optional for packaging.
As a Linux developer, when targeting windows, (the most used platform on the desktop), having the possibility to generate a windows installer is a necessity. In this case I see why I would need Docker.
But, as a windows developer, I usually only care about windows, and the Docker requirement becomes a painful point.

In the same way we have the --docker flag for hover run, I would also like to have it on packaging.

[GeertJohan]

Agree with @Drakirus

I also see how the --docker flag can be a bit confusing in combination with packaging. A user may read it as: package as a docker container image.

Perhaps --use-docker better describes what's going on?
If so, the flag name should also be changed for cross-compilng so it's a consistent experience for users. The flag --docker may be kept as hidden flag for a few months for backwards-compatibility, or just removed straight away.

[provokateurin]

The packaging for windows uses a tool called wixl which is only for linux. The original closed source program is called wixtoolset. My approach is to create true cross-packaging. wixl should be compatible with the wixtoolset, but maintaining 2 different versions of the code for windows / non-windows is not great for the overall maintainability.

[pchampio]

The packaging is a one-time process, and I don't think adding one or 2 other packaging systems hurts that much the maintainability. (And if not happy, user can still zip the build dir..)

Regarding this particular case of 'wixl' (linux tool to generate windows MSI) and 'wixtoolset' (window tool to generate windows MSI), I think it should be run by independent hover command, e.g.: hover build window-msi-onlinux and hover build window-msi.

IMHO: The docker feature can be added after each OS has a working packaging system. Because for now, we are only assuming that it is a valid demand. (Still, I'm a fan of hover build window-msi-onlinux and hover build window-msi, but not docker, at least for now)

[provokateurin]

My plan was to approach it like the cross-compiling:
Package from any OS for any OS using Docker.
For cross-compiling I could just have checked if the cross-compiling tools are available, but that would be just a mess.
So doing all cross-compiling and eventually all cross-packaging in Docker containers is the only possibility.
I think sticking with my current approach would be the best for the future of packaging.

[provokateurin]

The packaging formats I created which work on all OSs using Docker:
linux-deb: https://github.com/jld3103/hover/tree/feature/cross-packaging
linux-snap: https://github.com/jld3103/hover/tree/feature/cross-packaging
linux-appimage: https://github.com/jld3103/hover/tree/feature/packaging/linux-appimage
windows-msi: https://github.com/jld3103/hover/tree/feature/packaging/windows-msi
darwin-bundle: https://github.com/jld3103/hover/tree/feature/packaging/darwin-bundle
darwin-pkg: https://github.com/jld3103/hover/tree/feature/packaging/darwin-pkg

They all have only Docker as their dependency at work cross platform. I don't see a reason to not use only Docker for packaging.

[GeertJohan]

I'm convinced about going docker-only for now, these are good arguments @jld3103

[GeertJohan]

I'm attempting merge with master (there are some conflicts).

[pchampio]

We should keep this flag on hover run