Fix some bugs in the NDMP implementation.

Up until now we were not fully RFC compliant. You need to restore the full NDMP
environment returned during a NDMP backup when performing a NDMP restore. We more
or less re-created the environment when doing a restore but were missing some important
elements. We now save the full environment in the database and use that to restore
the whole environment when doing a restore.
Rework database scripting.

Having the actual DDL (Data Definition Language) in scripts is not very
flexible so we move all DDL into seperate files. We also dropped all
database specific scripting and as such the generic script now knows
for all supported database types what to do on create/update/grant and
drop.

You can also have a read-only user on your database that is allowed
to select stuff but not anything else that might be interesting for
Management Queries.

The update script now can also upgrade from a database that is several
versions old. For now that means you can upgrade from a Bacula database
to the first Bareos database schema and also to the new Database schema
we are introducing with this patch. For the future it means the script
will perform all needed updates for you if its has the wanted so called
conversion available (e.g. the way to go from one version to an other.)

We also added more functionality to the bareos-config script and splitted
the function into a bareos-config-lib which can be included by scripts
so they can get config information like the working dir etc. This is
already used in all the new database scripts.

We also no longer use explicit absolute pathnames for database utilities
but make sure the utility can be found via the PATH, if your PATH already
provides the utility it will be used and otherwise the value will be used
that was determined at compile time.

Fixes #236: Hardcoded path for postgres (verison) in scripts
Allow updates from Bacula 2.x to Bareos.

Now that we have a smart database update script we can add the other
database conversion scripts and allow a user to update his database
also from an older Bacula version. (2.0 is what we cut off with the
client so also for the server it makes sense to not support
anything older.)
SD to SD replication makes SD crash

Problem is that we wait up to 30 minutes for the SD-SD replication
job to start but it could be that the total migration/copy run takes
longer then 30 minutes to finish all jobs. The current code doesn't take
this into consideration and doesn't check if there is actually a remote
SD that connected for doing the replication.

So fix is to not continue when sd replication socket is not connected.
And also remove the timeout on starting a SD-SD replication session.
The normal FD-SD connection is protected with a timeout so we don't hang
when a FD never connects. As we support canceling a storage Job from the
director and the director should cleanly cancel the storage job any way
when it fails the copy or migration job it should be no problem.

In a normal backup/restore there are 3 daemons involved e.g. director,
storage daemon and file daemon but with migration the director controls
everything and controls the at maximum two storage daemons.

Fixes #276: SD to SD replication makes SD crash
Rebuild configure.
Fix for purge command not purging and truncating.

Fix for purge command not purging and truncating volumes when run
with action parameter

Fixes #282: Running purge command with action parameter does not purge
            or truncates volumes

Signed-off-by: Marco van Wieringen <marco.van.wieringen@bareos.com>