Improve checks for GUC recovery_target_timeline

 Improve checks for GUC recovery_target_timeline
 
 Currently check_recovery_target_timeline() converts any value that is
 not "current", "latest", or a valid integer to 0.  So, for example, the
 following configuration added to postgresql.conf followed by a startup:
 recovery_target_timeline = 'bogus'
 recovery_target_timeline = '9999999999'
 
 ...  results in the following error patterns:
 FATAL:  22023: recovery target timeline 0 does not exist
 FATAL:  22023: recovery target timeline 1410065407 does not exist
 
 This is confusing, because the server does not reflect the intention of
 the user, and just reports incorrect data unrelated to the GUC.
 
 The origin of the problem is that we do not perform a range check in the
 GUC value passed-in for recovery_target_timeline.  This commit improves
 the situation by using strtou64() and by providing stricter range
 checks.  Some test cases are added for the cases of an incorrect, an
 upper-bound and a lower-bound timeline value, checking the sanity of the
 reports based on the contents of the server logs.
 
 Author: David Steele <david@pgmasters.net>
 Discussion: https://postgr.es/m/e5d472c7-e9be-4710-8dc4-ebe721b62cea@pgbackrest.org