tree: Fix various typos and outdated terminology

This was mostly machine generated with the following command:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).

Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.

There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.

If I’ve missed anything, please file an issue!

Signed-off-by: Philip Withnall <withnall@endlessm.com>

docs/reference/glib/changes.xml

@@ -12,7 +12,7 @@
 <refnamediv>
 <refname>Changes to GLib</refname>
 <refpurpose>
-Incompatible changes made between successing versions of GLib
+Incompatible changes made between successive versions of GLib
 </refpurpose>
 </refnamediv>
 

docs/reference/glib/gvariant-text.xml

@@ -288,7 +288,7 @@
    </para>
    <para>
     Unicode escapes of the form <literal>\uxxxx</literal> and <literal>\Uxxxxxxxx</literal> are supported, in
-    hexidecimal.  The usual control sequence escapes <literal>\a</literal>, <literal>\b</literal>,
+    hexadecimal.  The usual control sequence escapes <literal>\a</literal>, <literal>\b</literal>,
     <literal>\f</literal>, <literal>\n</literal>, <literal>\r</literal>, <literal>\t</literal> and
     <literal>\v</literal> are supported.  Additionally, a <literal>\</literal> before a newline character causes
     the newline to be ignored.  Finally, any other character following <literal>\</literal> is copied literally
@@ -296,7 +296,7 @@
     additions you should only use this feature when necessary for escaping backslashes or quotes.
    </para>
    <para>
-    The usual octal and hexidecimal escapes <literal>\0nnn</literal> and <literal>\xnn</literal> are not
+    The usual octal and hexadecimal escapes <literal>\0nnn</literal> and <literal>\xnn</literal> are not
     supported here.  Those escapes are used to encode byte values and GVariant strings are Unicode.
    </para>
    <para>
@@ -309,10 +309,10 @@
    <para>
     Numbers are given by default as decimal values.  Octal and hex values can be given in the usual way (by
     prefixing with <literal>0</literal> or <literal>0x</literal>).  Note that GVariant considers bytes to be
-    unsigned integers and will print them as a two digit hexidecimal number by default.
+    unsigned integers and will print them as a two digit hexadecimal number by default.
    </para>
    <para>
-    Floating point numbers can also be given in the usual ways, including scientific and hexidecimal notations.
+    Floating point numbers can also be given in the usual ways, including scientific and hexadecimal notations.
    </para>
    <para>
     For lack of additional information, integers will be parsed as int32 values by default.  If the number has a
@@ -575,7 +575,7 @@
    <para>
     Bytestrings support the full range of escapes that you would expect (ie: those supported by
     <link linkend='g-strcompress'><function>g_strcompress()</function></link>.  This includes the normal control
-    sequence escapes (as mentioned in the section on strings) as well as octal and hexidecimal escapes of the
+    sequence escapes (as mentioned in the section on strings) as well as octal and hexadecimal escapes of the
     forms <literal>\0nnn</literal> and <literal>\xnn</literal>.
    </para>
    <para>

docs/reference/glib/gvariant-varargs.xml

@@ -690,7 +690,7 @@ g_variant_unref (value);]]></programlisting></informalexample>
     <link linkend='g-variant-get'><function>g_variant_get()</function></link> returns (by reference) a
     non-<link linkend='NULL:CAPS'><literal>NULL</literal></link> pointer.  When any of these format strings are
     prefixed with an '<literal>m</literal>', the type of arguments that are collected does not change in any way, but
-    <link linkend='NULL:CAPS'><literal>NULL</literal></link> becomes a permissable value, to indicate the Nothing case.
+    <link linkend='NULL:CAPS'><literal>NULL</literal></link> becomes a permissible value, to indicate the Nothing case.
    </para>
    <para>
     Note that the "special exception" introduced in the array section for constructing empty arrays is ignored

docs/reference/glib/regex-syntax.xml

@@ -2313,7 +2313,7 @@ refer to them instead of the whole pattern. In a larger pattern, keeping
 track of parenthesis numbers can be tricky. It may be more convenient to
 use named parentheses instead.
 The Perl syntax for this is (?&name); GRegex also supports the(?P>name)
-syntac. We could rewrite the above example as follows:
+syntax. We could rewrite the above example as follows:
 </para>
 
 <programlisting>

docs/reference/glib/running.xml

@@ -311,7 +311,7 @@ How to run and debug your GLib application
     <ulink url="https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling">Vectored Exception Handling</ulink>
     on Windows (see <link linkend="G_DEBUGGER"><envar>G_DEBUGGER</envar></link>), allowing GLib to catch more
     exceptions. Set this variable to a comma-separated list of
-    hexademical exception codes that should additionally be caught.
+    hexadecimal exception codes that should additionally be caught.
   </para>
   <para>
     By default GLib will only catch Access Violation, Stack Overflow and