docs: Update various outdated links which pointed to wiki.gnome.org

wiki.gnome.org has been retired but for some reason none of the old
pages were given HTTP redirects, so everyone has to update all their
links manually everywhere.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

CONTRIBUTING.md

@@ -22,7 +22,7 @@ many things that we value:
 Please, do not use the issue tracker for support questions. If you have
 questions on how to use GLib effectively, you can use:
 
- - the `#gtk` channel on [Matrix](https://wiki.gnome.org/GettingInTouch/Matrix)
+ - the `#gtk` channel on [Matrix](https://handbook.gnome.org/get-in-touch/matrix.html)
  - the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib)
 
 You can also look at the [`glib` tag on Stack
@@ -127,7 +127,7 @@ can be found on [the GNOME Developer Center](https://developer.gnome.org).
 
 The [GLib project uses GitLab](https://gitlab.gnome.org/GNOME/glib/) for code
 hosting and for tracking issues. More information about using GitLab can be
-found [on the GNOME wiki](https://wiki.gnome.org/GitLab).
+found [on the GNOME wiki](https://handbook.gnome.org/infrastructure/gitlab.html).
 
 ### Getting started
 
@@ -269,4 +269,4 @@ GLib to follow a few rules:
 
 If you have been contributing to GLib for a while and you don’t have commit
 access to the repository, you may ask to obtain it following the [GNOME account
-process](https://wiki.gnome.org/Infrastructure/NewAccounts).
+process](https://handbook.gnome.org/infrastructure/accounts.html).

docs/backports.md

@@ -30,7 +30,7 @@ Policy
    - If unavoidable, liaise with the GNOME Translation Team and ensure string
      changes are landed with plenty of time to allow translators to provide new
      translations
-   - See https://wiki.gnome.org/TranslationProject/HandlingStringFreezes
+   - See https://handbook.gnome.org/release-planning/freezes.html#string-freeze
  * API or ABI changes (including API additions) must not be backported
    - A commit which changes the documented behaviour of a function counts as an
      API break

docs/issue-and-merge-request-management.md

@@ -88,7 +88,7 @@ Several labels are worth highlighting:
    as confidential.
  * Merge After Freeze: Merge requests which have been accepted, but which can’t
    be merged yet as GLib is in
-   [code freeze](https://wiki.gnome.org/ReleasePlanning/Freezes). All MRs tagged
+   [code freeze](https://handbook.gnome.org/release-planning/freezes.html). All MRs tagged
    like this will be merged en-masse when the freeze ends.
  * Needs Information: Issues which are blocked due to needing more information
    from the reporter. These can be closed after 4 weeks if the reporter does not
@@ -105,10 +105,10 @@ Several labels are worth highlighting:
    the translation team to be looped into an issue or merge request.
  * API deprecation: Issues or merge requests which deprecate GLib API, and hence
    can only land in an unstable release outside an
-   [API freeze](https://wiki.gnome.org/ReleasePlanning/Freezes).
+   [API freeze](https://handbook.gnome.org/release-planning/freezes.html#api-abi-freeze).
  * New API: Issues or merge requests which add new GLib API, and hence can only
    land in an unstable release outside an
-   [API freeze](https://wiki.gnome.org/ReleasePlanning/Freezes).
+   [API freeze](https://handbook.gnome.org/release-planning/freezes.html#api-abi-freeze).
  * Intermittent: Issues (such as test failures) which can only be reproduced
    intermittently.
  * Test failure: Issues which revolve around a unit test failing. Typically

docs/releasing.md

@@ -21,7 +21,7 @@ How to make a release
 ---
 
 Broadly, GLib follows the same process as [every other GNOME
-module](https://wiki.gnome.org/MaintainersCorner/Releasing).
+module](https://handbook.gnome.org/maintainers/making-a-release.html).
 
 These instructions use the following variables:
  - `new_version`: the version number of the release you are making, for example `2.73.1`

docs/roadmap.md

@@ -27,7 +27,7 @@ Unstable release planning
 
 At the start of a development cycle, milestones are created for each release in
 the cycle according to the [GNOME release
-schedule](https://wiki.gnome.org/Schedule). GLib roughly follows the GNOME
+schedule](https://release.gnome.org/calendar/). GLib roughly follows the GNOME
 release schedule, but makes its releases one or two weeks ahead of each
 corresponding GNOME release. This allows other GNOME modules to depend on the
 correct GLib version for new APIs. GLib does not follow the GNOME module
@@ -42,7 +42,7 @@ maintainers think will have a wide benefit are prioritised.
 
 As a development cycle progresses, some of the releases are timed to coincide
 with [GNOME’s API/feature, string and hard code
-freezes](https://wiki.gnome.org/ReleasePlanning/Freezes). Issues which add API
+freezes](https://handbook.gnome.org/release-planning/freezes.html). Issues which add API
 and features are scheduled for the earlier micro releases in a development
 cycle, followed by issues which add or change translatable strings, followed by
 smaller bug fixes, documentation and unit test updates.

docs/supported-platforms.md

@@ -31,7 +31,7 @@ GLib is regularly built on at least the following systems:
  * Fedora: http://koji.fedoraproject.org/koji/packageinfo?packageID=382
  * Ubuntu: http://packages.ubuntu.com/source/glib2.0
  * Debian: https://packages.debian.org/experimental/libglib2.0-0
- * FreeBSD: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
+ * FreeBSD: https://cgit.freebsd.org/ports/tree/devel/glib20
  * openSUSE: https://build.opensuse.org/package/show/GNOME:Factory/glib2
  * CI runners, https://gitlab.gnome.org/GNOME/glib/blob/main/.gitlab-ci.yml:
    - Fedora (39, https://gitlab.gnome.org/GNOME/glib/-/blob/main/.gitlab-ci/fedora.Dockerfile)