Failure to distinguish these cases is the real cause behind the recent
reports of Windows builds crashing on 'infinity'::timestamp, which was
directly due to failure to establish a value of timezone_abbreviations
in postmaster child processes.  The postmaster had the desired value,
but write_one_nondefault_variable() didn't transmit it to backends.

To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
computed during initialization.  (We need both because there's at least
one variable that could receive a value from either source.)

This commit also fixes ProcessConfigFile's failure to restore the correct
default value for certain GUC variables if they are set in postgresql.conf
and then removed/commented out of the file.  We have to recompute and
reinstall the value for any GUC variable that could have received a value
from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
number of oversights.  (That whole thing is a crock that needs to be
redesigned, but not today.)

However, I intentionally didn't make it work "exactly right" for the cases
of timezone and log_timezone.  The exactly right behavior would involve
running select_default_timezone, which we'd have to do independently in
each postgres process, causing the whole database to become entirely
unresponsive for as much as several seconds.  That didn't seem like a good
idea, especially since the variable's removal from postgresql.conf might be
just an accidental edit.  Instead the behavior is to adopt the previously
active setting as if it were default.

Note that this patch creates an ABI break for extensions that use any of
the PGC_S_XXX constants; they'll need to be recompiled.