scanner: Handle constructors with mismatched GTypes

For historical reasons, we have boxed types that do not follow the typical conversion from CamelCase to snake_case when it comes to their get_type function.

The introspection scanner will correctly detect that a type is matched to that get_type function, but then it will default to tokenize the get_type function to set the c_symbol_prefix of the given type.

The method pairing code in the main transformation path takes that mismatch into consideration, but the constructor pairing code does not. This leads to interesting cases, like GString.

GString is correctly detected as GLib.String, and correctly matched to its g_gstring_get_type() type function, but its c_symbol_prefix is set to gstring after the tokenization. While methods like g_string_append() are correctly paired to the GLib.String node, constructors like g_string_new() do not, and end up being turned into function nodes, like GLib.string_new, even if they are annotated as constructors.

I'm not entirely confident that changing the c_symbol_prefix tokenization this late in the game is going to be free of regressions; instead, we provide a way for pairing constructors if they are annotated as such.

In other words: non-annotated constructors of types that have a different symbol prefix than the one of the get_type function will stay as they are today—a global function. To enforce the matching, we rely on an explicit (constructor) annotation; at least, this should ensure that we have explicit buy in from the maintainers of the API.

Fixes: #399 (closed)