modernize: Reformat ALL the source... again!

modernize: Reformat ALL the source... again!

It's been more than six years since we last used an autoformatter
on the codebase. Tooling has progressed, so has the language and
of course our personal preferences.

Use clang-format this time to reformat the whole codebase, following
the rules laid out in .clang-format (which one can use for configuring
an IDE, too, if it supports autoformatting). Overall, the new style
is not too different from what we used before, with one significant
change:

We now attach pointer/reference indicators (*&) to the type rather
than the name, i.e. we left-align. While this is a major deviation
from the Qt style which we use for almost everything else, it aligns
more closely with many other projects, as well as the C++
documentation and STL. It also makes more sense semantically,
because */& are really part of the type.

Other changes include (but are not limited to):

- Use only one blank line between function definitions
- Categorize includes from generic/system to local, sorting each
  category alphabetically. The generic-to-local sort order seems to
  be more common than the other way round, so we use that.
- In .cpp files, the corresponding header is always included first.
  This is a general recommendation, because it makes it harder to
  accidentally introduce a reliance on transitive includes in headers.
- Consistently break initializers in ctors before the comma, so the
  commas are left-aligned together with the colon.
- Use two spaces between code and trailing comments.

Note that sometimes even clang-format gets things wrong. In a few
places, formatting was manually fixed; however, reviewing a diff of
almost 80k lines is a rather boring task, so we didn't thoroughly
go through all the changes. Wrong formatting can always be fixed
in follow-up commits, anyway.

Note also that we don't intend to re-run clang-format on a regular
basis, nor do we want to religiously follow a hardcoded set of rules
for new code in the future. Where it makes sense, the rules may be
bent in favor of better readability or more pleasing code.