Refactor per-destination file rotation in logging collector

Refactor per-destination file rotation in logging collector

stderr and csvlog have been using duplicated code when it came to the
rotation of their file by size, age or if forced by a user request
(pg_ctl logrotate or the SQL function pg_rotate_logfile).  The main
difference between both is that stderr requires its file to always be
opened, so as it is possible to have a redirection route if the logging
collector is not ready yet to do its work if alternate destinations are
enabled.

Also, if csvlog gets disabled, we need to close properly its meta-data
stored in the logging collector (last file name for current_logfiles and
fd currently open for business).  Except for those points, the code is
the same in terms of error handling and if a file should be created or
just continued.

This change makes the code simpler overall, and it will help in the
introduction of more file-based log destinations.  This refactoring is
similar to the work done in 5b0b699.  Most of the duplication originates
from fd801f4.

Some of the TAP tests of pg_ctl check the case of a forced log rotation,
but this is somewhat limited as there is no coverage for
log_rotation_age or log_rotation_size (these may not be worth the extra
resources to run either), and no coverage for reload of log_destination
with different combinations of stderr and csvlog.  I have tested all
those cases separately for this refactoring.

Author: Michael Paquier
Discussion: https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com