Improve verification of recovery_target_timeline GUC.

Hackers,

Currently check_recovery_target_timeline() converts any value that is 
not current, latest, or a valid integer to 0. So for example:

recovery_target_timeline = 'currrent'

results in the following error:

FATAL:  22023: recovery target timeline 0 does not exist

Since there is no range checking for uint32 (but there is a cast from 
unsigned long) this setting:

recovery_target_timeline = '9999999999'

results in the following error (on 64-bit):

FATAL:  22023: recovery target timeline 1410065407 does not exist

Improve by adding endptr checking to catch conversion errors and add 
range checking to exclude values < 2 and greater than UINT_MAX.

I discovered this while testing on Postgres versions < 12 where

recovery_target_timeline = 'current'

sets the target timeline to 'latest', which is a pretty surprising 
result. I'm only noting it in case somebody is searching the archives 
since the versions in question are EOL. But that odd result made me 
wonder if Postgres >= 12 had a similar problem. While it is not quite so 
confusing as Postgres < 12 I think it still bears improving.

The tests are probably excessive but I needed something to show that the 
verification works as expected.

Regards,
-David