Add configure flag --enable-gtk3 to build against GTK 3.x
Don't access GtkWidget fields directly

Since many accessor are new in GTK versions we don't depend on, add
a header that defines them to the direct access if they aren't
available.
Include keysyms compatibility header on GTK3
Guard removed dialog separators on GTK3

GtkDialog separators sere deprecated on GTK 2.22 and remove on 3.0,
so define them to dummy values on GTK3.

We don't get rid of them altogether because GTK 2.16 we depend on
probably has separators enabled by default and we want to remove them.
Get rid of GtkComboBoxEntry API and use GtkComboBoxText API

Use the GtkComboBoxText API and the GtkComboBoxEntry replacement API
and map those to the old equivalents if not available.

This changes the type exposed by ui_combo_box_add_to_history() from
GtkComboBoxEntry to either GtkComboBox (under GTK2) or GtkComboBoxText
(under GTK3).  This should not be too much of an issue since
GtkComboBoxEntry and GtkComboBoxtext are subclasses of GtkComboBox,
but this will still emit warnings when when the calling code passes
a GtkComboBoxEntry pointer to ui_combo_box_add_to_history().

However, this requires the calling code to use the same mapping as we
do (GtkComboBoxText = GtkComboBox on GTK2, even on 2.24), or things
will blow and it'll be hard to understand why.  This wouldn't be an
issue if the calling code includes our gtkcompat.h header everywhere
it deals with combo boxes, which will be the case if it includes the
Geany headers everywhere but probably won't otherwise.  Oh dear.

A possible kind of workaround may be for ui_combo_box_add_to_history()
to do type-checking on its argument and use the actually correct API
for that type.
Prevent most GTK3 deprecation warnings that can't be fixed on GTK2

Map the various horizontal and vertical deprecated constructors
to their GtkOrientation-based equivalents on GTK3 to prevent most
deprecation warnings.
Map GeanyWrapLabel to GtkLabel on GTK3

The GTK3 version of GtkLabel provides what GeanyWrapLabel is for given
the appropriate settings are set, so no need to our own widget -- that
would require being updated to support GTK3 anyway.
Add ::draw handler for GTK3 where we have ::expose-event handlers
Make X11 backend specific code GTK3-proof
Load GTK3 version of the VTE library when built against GTK3
Prevent plugins built against GTK2 Geany from loading in GTK3 Geany
Fix a packing issue on GTK3

GTK3 changed the default for expand and fill, so explicitly set them.
Don't use old GTK1-style typesystem

This fixes the SCINTILLA_CLASS() and IS_SCINTILLA() macros on GTK3.
No harm on GTK2, those macros are available since 2.0.

This also makes those macros more consistent with the SCINTILLA()
macro that already uses the proper GObject calls.

Backported from Scintilla HG: 9cd7cf1d9af73d50b0423ed34a6693bbf7f57ac8
Make GeanyWrapLabel work with GTK3

Although theoretically GtkLabel from GTK3 should be able to replace
GeanyWrapLabel altogether, a bug [1] with it makes it use way too much
space in our about dialog (and possibly other places), making it not
really usable.

So, port the GeanyWrapLabel hack to GTK3, with the appropriate
additional hacks for it to work.  At least it looks good and don't
seem to have resizing issues now.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=657621
Use GtkFontChooserDialog on GTK >= 3.2 for consistency

GtkFontButton uses GtkFontChooserDialog on GTK 3.2 so the UI is more
consistent if we use it explicitly too, and GtkFontSelectionDialog
is somewhat broken on 3.4.
Add GTK3 version of our custom styles

Although GTK3 still have gtk_rc_parse_string(), it doesn't work anymore
for our overrides, so register proper CSS for them.
Set the primary-toolbar CSS class on the main toolbar under GTK3

This makes the main toolbar look like other GTK3 application ones.
Printing: fix text resolution

Scintilla doesn't respect the context resolution, so we need to scale
its draws ourselves.
Printing: draw the vertical separator line more accurately

Use the dimensions and offsets used by Scintilla to position our
separator line, since its position depends on where Scintilla drawn.

Closes #3580268.
Printing: fix improper margins when printing to a physical device

We were improperly adding the printing device margins to the area
where we print, leading to wider margins on physical outputs than
on PDF or preview outputs (which have no hard margins), as well as
wasting space and not respecting user's settings.

Closes #3580269.