AFAIK this means on all platforms but Win32 and macOS which would rather
need relative path and therefore cannot make use of build-time
LIBEXECDIR. Anyway on these platforms, leaving the binary in BINDIR is
not likely to "pollute" too much as it would on Linux or BSD where
people often use terminal.

It was previously untested, hence as expected needed fixes. First I add
our own exception handler using Win32 API SetUnhandledExceptionFilter().
Second, I reorder things so that ExcHndlInit() is run after this setter,
since they will be executed as a FILO and we need backtraces to be
generated before our separate GUI runs. Last I run the backtrace GUI as
async. No need to keep the main GIMP waiting since the traces have
already been generated into a separate file.
Also replace gtk_show_uri() by the implementation taken straight from
our web-browser plug-in, since apparently gtk_show_uri() doesn't work in
Windows (and probably not macOS either since I see we have a separate
implementation for this platform as well). I would like to be able to
use the PDB but can't because this code needs to be usable both within
the main process and into a separate tool process. Ideally, this should
just be a utils function which could be included without a problem.

* Type pid_t is not cross-platform. Just use int instead, and convert it
to respective type on each platform.
* Get rid of several useless include which should have been removed a
few commits ago, when I reimplemented the backtrace function.
* Better handle the various macros in gimp_eek() (between G_OS_WIN32,
HAVE_EXCHNDL and GIMP_CONSOLE_COMPILATION, but also no_interface and
generate_backtrace options, that was a bit messy).
* Make gimpdebug now always built, whatever the platform.

The feature already exists in our code and produces backtraces upon a
crash into a file. The only difference is that we are now getting the
file contents and showing it in our new debug dialog, so that it works
similarly on all platform (and therefore making the debug info visible
to people, otherwise they would never report, even though the data is
generated).
The difference with gdb/lldb is that it doesn't allow backtraces at
random points (for debugging non-fatal yet bad errors). Also the API has
just 2 functions and in particular an ExcHndlInit() but no way to unload
the feature. So we don't need the debugging page in Preferences because
the switch option would not work. On Windows, the feature will be
decided at build time only.
Last point: the code is untested on Windows so far. I assume it would
work, but there is at least one point I am unsure of: will ExcHndl have
already generated the backtrace file when gimpdebug runs? If not, I will
have to let gimp die first to be able to get the backtrace.

This is just a bit more consistent with existing code. Also build the
gimpdebug tool only when GIMP_CONSOLE_COMPILATION is not set and run
when --no-interface CLI option is not set since it is a GUI tool.

This will determine whether to output backtrace in a GUI and is disabled
by default on stable, and activated in dev builds. It is a bit redundant
with --stack-trace-mode option CLI and will take priority when enabled
since most people would run GIMP with a graphical interface anyway.

This was a bit harder since even though we handle fatal signals,
allowing us to do any last action before GIMP crashes, it seems more
memory allocation is not allowed at this time. So creating a dialog or
simply getting the return output of gdb into the main process is not
allowed. What I do instead is running a separate program (gimpdebug)
which will take care of creating the new dialog and running a debugger.
I still use GimpCriticalDialog code from this separate binary, while I
continue to use this widget also within GIMP for non-fatal errors. The
reason why we still want to use it within GIMP is that we can bundle
several non-fatal errors and backtrace this way (fatal errors don't
return anyway) and it's easier to do so when created from the main
process.

Don't use g_on_error_stack_trace() from glib anymore. It is
over-complicated, using gdb in interactive mode and running command
writing in the pipe input. Sometimes it even gets stuck and never
return. This is useless since gdb even has a batch mode, to just run
commands and exit directly. I just use this.

GIMP will now try to get a backtrace (on Unix machines only for now,
using g_on_error_stack_trace(); for Windows, we will likely have to look
into DrMinGW).
This is now applied to CRITICAL errors only, which usually means major
bugs but are currently mostly hidden unless you run GIMP in terminal. We
limit to 3 backtraces, because many CRITICAL typically get into domino
effect and cause more CRITICALs (for instance when a g_return*_if_fail()
returns too early).

This reverts 2069496a for
gimpmeasuretool.c, we can't use gimp_display_shell_get_line_status()
here because the angle to show is *not* the angle as shown in the
paint tools (between x1,y1 and x2,y2), it is determined by a possible
third point.
Also, the info window and the statusbar were using different
coordintates to detemine the line length. This would have been easily
fixable, but the wrong angle wasn't.

Derive GimpUnifiedTransformTool, GimpPerspectiveTool, and
GimpHandleTransformTool from GimpGenericTransformTool, eliminating
their common logic.
Remove gimp_transform_matrix_handles(), which is no longer used.

... gimp_transform_matrix_generic()
Replace the separate x/y coordinate arrays of GimpHandleGrid with
GimpVector2 arrays, and use gimp_transform_matrix_generic(),
instead of gimp_transform_matrix_handles(), when calculating the
matrix. When the resulting matrix is invalid, hide the guides.

A subclass of GimpTransformTool, to be used as a base class for
transform tools that calculate their matrix based on 4 pairs of
input/output points, and that display the transform matrix as their
GUI (this includes the unified, perspective, and handle transform
tools; the next commit ports them over to
GimpGenericTransformTool).
When the resulting matrix of the input/output mapping sends any of
the output points to, or past, infinity, GimpGenericTransformTool
sets GimpTransformTool::transform_valid to FALSE, and displays an
appropriate message in the tool GUI, instead of showing the matrix.

... which specifies whether the transform matrix is valid.
Subclasses can then set this member to indicate that the current
transformation is invalid (which can happen in the unified,
perspective, and handle transform tools). When the transform is
invalid, GimpTransformTool doesn't apply it upon committing, and
returns an error instead.
This commit doesn't set the transform_valid member in any of the
subclasses, so there's no effective change. The next commit adds a
GimpGenericTransformTool subclass, that will use the new member.

... on top-level layers.
There was even a comment for this, but I missed this when I moved some
code to the top of the function in commit b9577a78. Now moving this
call up as well. This appeared to be more of a problem when merging
layers without a GUI (script-fu). I'm guessing the GUI calls this anyway
before.

Replace all g_assert_not_reached() in app/core/ by g_return_if_reached()
or g_return_val_if_reached(). GIMP may handle a lot of creative work,
sometimes unsaved for hours. We should not just crash on purpose.
g_assert*() could theoretically be turned off on a glib build, but this
is nearly never done, and is not a solution either (actually it is
probably even worse because the broken code would just continue on a
forbidden path). It is much better to return with a warning on such
forbidden code paths, allowing someone to report a bug without
experiencing a crash and data loss.
For now, I only took care of g_assert_not_reached() inside app/core.
More g_assert*() code should be replaced.
Note: assert are acceptable in plug-ins though, but not in the main
executable, unless absolutely necessary (something happening so bad that
crash is better than continuing).