gsignal: Correctly handle incorrect parameter counts in signal callbacks

This is a minefield.

g_signal_connect_swapped() is intended to be used in situations where
the number of formal parameters in the callback function differs from
the number of actual parameters emitted by the signal. This allows the
common idiom of (e.g.) calling gtk_widget_hide() on a signal callback
from another object, with the widget being passed in the user_data.

It turns out that these situations are entirely implementation defined.
The C specification disavows all knowledge of how parameter passing
should work when the callback function prototype isn’t known, leaving
this to the calling convention to define.

All calling conventions that we care about handle this sensibly,
explicitly covering the case of the number of actual parameters
exceeding the number of formal parameters, just like they handle
varargs. However, there are a few calling conventions which won’t handle
this properly, and will cause explosions should you try. For example, I
believe that passing a WinAPI function (calling convention: stdcall) as
a signal callback will cause problems. I haven’t verified this
experimentally though.

The gsignal-checker now allows for the number of formal and actual
parameters to differ, but only if the calling convention for the
callback function is safe. That should cover things.
gsignal: Add support for signals defined on interfaces

Previously the checker would not find the information about a signal
which was defined on an interface implemented by the dynamic instance
object (or one of its superclasses).
debug: Add support for emitting remark reports

These are less severe than warnings, and should be used in cases where
static analysis is hindered for some reason, but the code is otherwise
probably OK. For example, if the type of a variable cannot be determined
statically, and knowing the type would be really useful for analysis, a
remark could be emitted asking the user to add an explicit typecast.
gsignal: Improve warning messages if type information cannot be found

It is most likely due to a GIR containing the signal information not
being available. As such, make the messages remarks rather than
warnings.
gsignal: Assume GError types will be GError* in signals

…rather than GError**. If that were the case, multiple handlers for the
signal would collide on setting the GError. There is no way it could
work sensibly.
bugs: Add a comment about a GError bug
nullability: Replace (allow-none) with (nullable) and (optional)

Further work still needs to be done to take full advantage of the new
semantic distance between the two, but for the moment we can at least
update the compiler warnings to mention both new annotations.
bugs: File various new bugs from e-mail conversations with Guillaume
clang-plugin: Fix typo in command line documentation

The overall project is a plugin. The individual components it runs are
checkers.
scripts: Remove unused variable from wrapper script
plugin: Add a --quiet argument and output the Tartan version on startup

This makes it easier to tell from compiler output whether Tartan is
actually running, since this has been a point of confusion in the past.
bugs: Add tags and severity information to bugs
gsignal: Handle signal names containing underscores

It is perfectly valid to specify a signal name with hyphens or with
underscores, so support both in the checker.