docs: Soft-deprecate sized integer types in favour of (u)intN_t

This MR is now based on !3001 (merged) so I can use gsize as the type that has the (only) full explanation of the implications for API/ABI compatibility, instead of arbitrarily choosing one of the eight sized integer types to be the one that gets the full explanation. Please review !3001 (merged) first.

• docs: Clarify relationship between goffset and POSIX off_t

  The important thing here is that we can't arbitrarily mix these, even if they will often have the same in-memory representation.

  Helps: #1484 (closed)

• docs: Soft-deprecate sized integer types in favour of (u)intN_t

  C99 does not actually guarantee that the platform has 8-, 16-, 32- and 64-bit types, but it does guarantee that if the platform has them, then (u)intN_t are defined to be examples of those types.

  GLib goes beyond what C99 guarantees, and requires 8-, 16-, 32- and 64-bit types; combining that with C99's requirements means we can assume that int8_t, uint64_t, etc. all exist.

  Unfortunately, we cannot guarantee that GLib and the C99 toolchain have chosen the same fixed-size type: for example, on a typical ILP32 or LLP64 platform like Windows or 32-bit Linux, each 32-bit type could either be int or long, while on a LP64 platform like 64-bit Linux, each 64-bit type could either be long or long long. The in-memory representation is the same either way, but the choice of underlying type matters when building printf format strings or issuing compiler warnings. As a result, we can't just typedef gint32 as int32_t and so on.

  Resolves: #1484 (closed)