Rationalize unison as CLI and unison-gui as GUI for program names in all builds

[gdt]

This state should ensure as a side effect that CI artifacts will have a CLI binary that will work on a system without the GTK libraries, or with the misplaced or wrong kind of GTK libraries.

Keep in mind, thought, that unison doctrine is that CI is for CI and packaging systems should provide packages. However building from source should be clean and aligned with packaging norms, and that's what this ticket is about.

[gdt]

A complexity is that on Mac, one one build a Mac application, and the gtk version similar to other mostly-POSIX systems.

[gdt]

See also #394, which points out that the GHA build process results in unison and unison-gtk, which is aligned with how several packaging systems approach unison.

The point of this ticket is to change the build system to have separate binaries, and to be able to remove the workaround of renaming from GHA and packaging system builds.

[gdt]

This implies a removal of "UISTYLE", and targets unison, unison-gui, and something for the mac package. The target unison-gui should just fail if lablgtk3 is not available.

[gdt]

I have observed buggy behavior, all in src (because the top-level makefile does not work right with UISTYLE passthrough).

• With "make UISTYLE=text", I get a unison not linked with lablgtk (correct).
• Then, with "make UISTYLE=gtk3", I get a unison linked with gtk3.
• With "make UISTYLE=text", nothing happens, but the unison binary is still linked with lablgtk.
• After removing the file unison, making again with UISTYLE=text results in a binary not linked with lablgtk.
  If instead I build gtk3 first, the situation is reversed.

Basically, UISTYLE violates a basic rule of command-line variables (or environment vairables) and make: If you use them, you have to start from clean, and then on every later invocation of make the variable has to have the same value. That's not how the unison build system is used.