Point to discourse, rather than mailing lists.
Based on a suggestion by sujiniku,

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1763

gitlab reads the new filename but not the old one.

The section is about rules for direct commit access to the upstream
repository, so let's be more clear about it.

Link to the GitLab documentation, and clarify that if no single commit
in a merge requests closes an issue, you should add a reference to the
issue in the commit message anyway.

This is an important document for newcomers, so we should err on the
side of being more detailed on what kind of contributions we expect,
and how we expect them.

The text is heavily modelled on the contributing-template by Nadia
Eghbal available here:

  https://github.com/nayafia/contributing-template

There's no point in having a separate file detailing how commits ought
to work, considering we already have a contribution guide.

When filing a new merge request it's often hard to know who to ask for a
review; using the Git log doesn't always help — the person that touched
a file last may just be fixing the build or a compiler warning.

The `CODE-OWNERS` file format is something that GitHub uses in order to
pre-fill the list of reviewers:

  https://help.github.com/articles/about-codeowners/

Ideally, in the future, we'll be able to use this file with a bot like
homu to automatically go through newly filed merge requests and
automatically ask the relevant people for reviews, instead of doing this
manually.