docs: Modify include ordering paragraph to order linux headers last

All linux headers include "libc-compat.h" which checks whether various
glibc headers have already been included and if that's the case, sets
various defines which instruct the other linux headers to skip defining
various definitions themselves to avoid conflicts.

Unfortunately, various glibc headers are missing similar checks, most
notable <netinet/in.h> and <net/if.h>. This means that if the linux headers
are included before the glibc ones, including the glibc ones will cause
compilation errors due to redefining structs.

Note that including the relevant glibc header before the corresponding
linux header (e.g. <netinet/in.h> before <linux/in.h> is not sufficient,
as all linux headers include libc-compat.h and libc-compat.h checks once
(the first time it's included) which relevant glibc headers have been
included by that point and sets in stone what the other linux headers will
do when included. So if <linux/if_arp.h> is included first, followed by
<netinet/in.h> followed by <linux/in.h>, parsing <linux/in.h> will still
fail because <linux/if_arp.h> will include <linux/libc-compat.h>, which
will check if <netinet/in.h> has already bee included, which isn't the
case, and so it will instruct <linux/in.h> to define all its structs, which
will cause redefinitions errors because <netinet/in.h> will also include all
its structs.

Even if glibc fixes its <netinet/in.h> header to not define structs that
have already been defined by <linux/in.h>, the above scenario would still fail,
as <linux/libc-compat.h> would still tell <linux/in.h> to define all its structs,
and <netinet/in.h> would also still define all its structs as <linux/in.h> hasn't
been included yet by the time <netinet/in.h> is included.

Author: DaanDeMeyer

docs/CODING_STYLE.md

@@ -344,15 +344,17 @@ SPDX-License-Identifier: LGPL-2.1-or-later
   }
   ```
 
-- The order in which header files are included doesn't matter too
-  much. systemd-internal headers must not rely on an include order, so it is
-  safe to include them in any order possible.  However, to not clutter global
-  includes, and to make sure internal definitions will not affect global
-  headers, please always include the headers of external components first
-  (these are all headers enclosed in <>), followed by our own exported headers
-  (usually everything that's prefixed by `sd-`), and then followed by internal
-  headers.  Furthermore, in all three groups, order all includes alphabetically
-  so duplicate includes can easily be detected.
+- systemd-internal headers must not rely on an include order, so that it is safe
+  to  include them in any order possible. To not clutter global includes, and to
+  make sure internal definitions will not affect global headers, please always
+  include the headers of external components first (these are all headers
+  enclosed in <> except `<linux/*.h>` headers), followed by our own exported
+  headers (usually everything that's prefixed by `sd-`), then followed by
+  internal headers and finally end with any `<linux/*.h>` headers. Linux headers
+  have to be included last as they are parsed differently depending on which
+  glibc headers have already been included by the time the first linux header is
+  parsed. Furthermore, in all four groups, all includes should be ordered
+  alphabetically.
 
 - Please avoid using global variables as much as you can. And if you do use
   them make sure they are static at least, instead of exported. Especially in