Rename GTK+ to GTK (mostly comments and documentation)

GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>

This commit can be re-generated with:

    git grep -l GTK+ \
    | grep -v -e ^NEWS -e ^glib/tests/collate.c \
    | xargs sed -i 's/GTK+/GTK/g'

Most of the changes are in comments and documentation.

docs/reference/gio/overview.xml

@@ -154,7 +154,7 @@
   </para>
 
   <figure id="gvfs-overview">
-    <title>GIO in the GTK+ library stack</title>
+    <title>GIO in the GTK library stack</title>
     <graphic fileref="gvfs-overview.png" format="PNG"></graphic>
   </figure>
 
@@ -166,7 +166,7 @@
   </para>
   <para>
     One of the big advantages of putting the VFS in the GLib layer
-    is that GTK+ can directly use it, e.g. in the filechooser.
+    is that GTK can directly use it, e.g. in the filechooser.
   </para>
   </chapter>
 

docs/reference/glib/building.xml

@@ -49,7 +49,7 @@
       aliasing and cannot be guaranteed to work.
     </para>
     <para>
-      The GTK+ documentation contains
+      The GTK documentation contains
       <ulink url="https://developer.gnome.org/gtk3/stable/gtk-building.html">further details</ulink>
       about the build process and ways to influence it.
     </para>

docs/reference/gobject/tut_gobject.xml

@@ -19,7 +19,7 @@
       <listitem><para>Generic per-object properties with set/get function pairs</para></listitem>
       <listitem><para>Easy use of signals</para></listitem>
     </itemizedlist>
-    All the GNOME libraries which use the GLib type system (like GTK+ and GStreamer)
+    All the GNOME libraries which use the GLib type system (like GTK and GStreamer)
     inherit from <link linkend="GObject"><type>GObject</type></link> which is why it is important to understand
     the details of how it works.
   </para>

docs/reference/gobject/tut_gsignal.xml

@@ -10,7 +10,7 @@
 
     <para>
       Closures are central to the concept of asynchronous signal delivery
-      which is widely used throughout GTK+ and GNOME applications. A closure is an 
+      which is widely used throughout GTK and GNOME applications. A closure is an 
       abstraction, a generic representation of a callback. It is a small structure
       which contains three objects:
       <itemizedlist>
@@ -37,9 +37,9 @@ return_type function_callback (… , gpointer user_data);
       <footnote><para>
         In practice, closures sit at the boundary of language runtimes: if you are
         writing Python code and one of your Python callbacks receives a signal from
-        a GTK+ widget, the C code in GTK+ needs to execute your Python
-        code. The closure invoked by the GTK+ object invokes the Python callback:
-        it behaves as a normal C object for GTK+ and as a normal Python object for
+        a GTK widget, the C code in GTK needs to execute your Python
+        code. The closure invoked by the GTK object invokes the Python callback:
+        it behaves as a normal C object for GTK and as a normal Python object for
         Python code.
       </para></footnote>
       The GObject library provides a simple <link linkend="GCClosure"><type>GCClosure</type></link> type which
@@ -179,8 +179,8 @@ g_cclosure_marshal_VOID__INT (GClosure     *closure,
     <para>
       GObject's signals have nothing to do with standard UNIX signals: they connect 
       arbitrary application-specific events with any number of listeners.
-      For example, in GTK+, every user event (keystroke or mouse move) is received
-      from the windowing system and generates a GTK+ event in the form of a signal emission
+      For example, in GTK, every user event (keystroke or mouse move) is received
+      from the windowing system and generates a GTK event in the form of a signal emission
       on the widget object instance.
     </para>
 

docs/reference/gobject/tut_howto.xml

@@ -17,7 +17,7 @@
   
   <para>
     This chapter focuses on the implementation of a subtype of GObject, for
-    example to create a custom class hierarchy, or to subclass a GTK+ widget.
+    example to create a custom class hierarchy, or to subclass a GTK widget.
   </para>
 
   <para>
@@ -55,7 +55,7 @@
         <filename>viewer_file.c</filename>.</para></listitem>
         <listitem><para>Do not separate the prefix from the typename:
         <filename>viewerfile.h</filename> and <filename>viewerfile.c</filename>.
-        (this is the convention used by GTK+)</para></listitem>
+        (this is the convention used by GTK)</para></listitem>
       </itemizedlist>
       Some people like the first two solutions better: it makes reading file
       names easier for those with poor eyesight.

docs/reference/gobject/tut_intro.xml

@@ -6,7 +6,7 @@
   <title>Background</title>
   
   <para>
-    GObject, and its lower-level type system, GType, are used by GTK+ and most GNOME libraries to
+    GObject, and its lower-level type system, GType, are used by GTK and most GNOME libraries to
     provide:
     <itemizedlist>
       <listitem><para>object-oriented C-based APIs and</para></listitem>

docs/reference/gobject/tut_tools.xml

@@ -62,7 +62,7 @@
         Yet another tool that you may find helpful when working with
         GObjects is <ulink
         url="http://sourceforge.net/projects/g-inspector">G-Inspector</ulink>. It
-        is able to display GLib/GTK+ objects and their properties.
+        is able to display GLib/GTK objects and their properties.
       </para>
   </chapter>
   
@@ -90,7 +90,7 @@ break g_object_unref if _object == 0xcafebabe
   <chapter id="tools-gtkdoc">
     <title>Writing API docs</title>
   
-    <para>The API documentation for most of the GLib, GObject, GTK+ and GNOME
+    <para>The API documentation for most of the GLib, GObject, GTK and GNOME
     libraries is built with a combination of complex tools. Typically, the part of 
     the documentation which describes the behavior of each function is extracted
     from the specially-formatted source code comments by a tool named gtk-doc which

docs/toolchain-requirements.md

@@ -139,7 +139,7 @@ Selected C99 features
 
 _Hard requirement._
 
-Starting with GLib 2.52 and GTK+ 3.90, we will be using the following C99
+Starting with GLib 2.52 and GTK 3.90, we will be using the following C99
 features where appropriate:
 
  * Compound literals