Tag v1.3.8

[#75] Allows usage of externally managed on-disk PostgreSQL versions

If the user creates a directory in `PGENV_ROOT` with the same layour
of another `pgsql-xxx` directory, and the name with the prefix
`pgsql-`, such directory will be usable by `pgenv use` and subsequent
commands.
This allows, for example, to manage a checked out directory from
another repository via `pgenv` as if it was installed by `pgenv` itself.

[#71] Add support for "run once" custom script

This commit introduces a new configuration parameter
`PGENV_SCRIPT_FIRSTSTART` that can be pointed to an executable that is
run once and only once at the very first start of the selected
instance.
Therefore, the usage of this script enables for customization of the
instance, like for example adding new users and databases.

The changes are made directly into the `pgenv_start_instance`
function, that is the entry point to a start action: the function in
turns calls `pgenv_initdb` that performs the initialization of the
instace. If the initialization is done, a new magic variable
`PGENV_INITDB_DONE` is set to `1`, so that `pgenv_start_instance` can
then decide to execute the script mentioned above.

Therefore, the trick here is to mark a "first start" time as the one
that immediatly follows the initdb phase.

Documentation updated.
Version number bumped.

Close #71

[#71] Add support for "run once" custom script

This commit introduces a new configuration parameter
`PGENV_SCRIPT_FIRSTSTART` that can be pointed to an executable that is
run once and only once at the very first start of the selected
instance.
Therefore, the usage of this script enables for customization of the
instance, like for example adding new users and databases.

The changes are made directly into the `pgenv_start_instance`
function, that is the entry point to a start action: the function in
turns calls `pgenv_initdb` that performs the initialization of the
instace. If the initialization is done, a new magic variable
`PGENV_INITDB_DONE` is set to `1`, so that `pgenv_start_instance` can
then decide to execute the script mentioned above.

Therefore, the trick here is to mark a "first start" time as the one
that immediatly follows the initdb phase.

Documentation updated.
Version number bumped.

Close #71

[#70] Fix bug in running post-initdb script

For some strange reason, the post-initdb script holding variable was
named `PGENV_SCRIPT_INITDB` but in the configuration was searched for
as `PGENV_SCRIPT_POSTINITDB`. Since the configuration generates the
latter, I fixed the test in `pgenv_initdb()` to use
`PGENV_SCRIPT_POSTINITDB`.

Bumps the version number.

Close #70

Environment variable to prevent automatic configuration file creation. (

#64)

* Environment variable to prevent config file overwriting.

The variable `PGENV_WRITE_CONFIGURATION_FILE_AUTOMATICALLY`
is used to instrument `pgenv` to decide about the need to
write/overwrite the configuration file at the end
of a build/rebuild process.

If the variable is not set, or set to a true value (i.e., not zero,
not "NO" - case insensitive), the configuration file will be
written and/or overwritten.
If the variable is set to zero or "no" (case insensitive), the
configuration
file will not be written.

Close #62

Remove `declare` from array definitions.

`declare -a` is used for arrays when `declare -p` dumps the
configuration. However when `pgenv_configuration_read` gets back the
configuration, variables becomes locally scoped (see `bash -c "help
declare"). One solution could be to use `declare -g` to make variables
globals, but this does not works on OSX.
Removing `declare -a` (and -x) from arrays seems to make the variable global
even if no `EXPORT` is issued. As a possible compatibility statement,
the `EXPORT` after each variable is left in place.

Close #56

Use `export` also in commented out variables.

Place the export command also on configuration lines that are
commented out, so that the user can easily uncomment those lines and
get the variable globally scoped.

See #54

New version.

With the addition of `switch` it does make sense to have a new version.

Use global variable definition into configuration.

As reported in issue #52, the automatically generated configuration
exploits Bash `declare` to define variable. When
`pgenv_configuration_load` does `source` the configuration file,
declared variables are locally scoped as reported in the `declare`
help:

    When used in a function, `declare' makes NAMEs local, as with the `local'
    command.  The `-g' option suppresses this behavior.

Therefore every `declare` statement has to be prefix with
`-g`. Unluckily it seems that the counterpart `declare`, used to print
out the variable in `pgenv_configuration_write` does not outputs the
`-g` flag, probably because at that time the variable is already
global.
Therefore, before hitting the configuration file, I append the `-g`
option to `declare` with a regexp.

This `-g` works on Bash 4.4 and 5 on my Linux machines.

Bumped version number.

Close #52