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