clean up size_t/ssize_t use with POSIX file system APIs

Here is a patch series to clean up the use of size_t and ssize_t with
POSIX file system APIs (read, write, etc.) and the APIs that PostgreSQL
has built on top.

Most newer code already did this correctly, but some older code did not
and mostly used int or some other randomness. Which also sometimes
leads to odd back-and-forth at different API layers.

Aside from consistency and basic correctness, this also helps in other ways.

It makes error messages more consistent. Consider the current potpourri
like

read %d of %d
read %d of %lld
read %d of %u
read %d of %zu
read %lld of %lld
read %zd of %lld
read %zd of %zu
read %zu of %zu

Once we get all of this aligned better, there might also be some
opportunities to refactor some repeated combinations like read/write +
error checking + pgstat report.

Another advantage of correctly using size_t instead of int is that you
don't have to wonder whether a negative value might be passed and what
to do with it.

Also, of course, we do want to actually support large files in some
situations. I don't think it currently matters in practice for the
places I changed here, but it might in the future, or if this code gets
expanded or copied around.

Some patches have some additional details that are noted in the commit
messages, but most of it is relatively straightforward replacement and
some cosmetic adjustments.

(Note: There are similar issues with network functions recv()/send(),
but there are weird complications related to Windows, different API
wrappers in used for frontends and backends, so I left those out for now.)

The patches related to casts of pgoff_t are included here (0002 and
0003) here because they are prerequisites, but there is a separate
thread for those at [0].

[0]:
https://www.postgresql.org/message-id/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org