Only mount shared DB drive if already mounting

This shifts the default behavior for VVV to non-persisting
databases. If an existing VM is already storing database data on
the guest machine, drives will continue to mount. If you remove
this data or start fresh with VVV, the MySQL directory will not
be stored on your computer.

This addresses the pain that is #287 and moves to a model that
(to me) makes more sense at all.

We'll probably want to think of ways we can avoid data loss by
making it easy to backup data on a regular basis as required.
Introduce vagrant_halt homebin file to run on halt

If the vagrant-triggers plugin is installed, the vagrant_halt
script will fire immediately before the virual machine is halted
after issuing the `vagrant halt` command.

This script can be used to perform useful cleanup and backup tasks,
though other backup options should always be used for critical data.

Next we can add a hook to a custom script so that additional tasks
can be added without worrying about maintaining upstream compatibility
Add triggers for destroy and suspend

We can add triggers for a bunch of different Vagrant commands, but
the ones that bring down a VM seem most important in the near term
for things like backing up databases. This commit adds support for
both `vagrant destroy` and `vagrant suspend`. We can revisit
`vagrant up`, `vagrant resume`, etc... in the future.
Add README item for vagrant-triggers installation

We can fill this out a bit once we know what the scripts will
actually be doing.
Allow for custom trigger scripts

This sets each of the included trigger scripts to call a possible
custom trigger script. These can be used to perform various tasks
when the state of your virtual machine is about to be changed via
the Vagrant command line.
Handle custom and default triggers as either or

If a custom trigger script exists, we won't do anything in VVV.
Introduce db_backup command to backup databases

Introduces a home/vagrant/bin/db_backup that creates SQL dumps for
each of the databases setup in MySQL. These files overwrite existing
previous versions in the database/backups directory in the local
environment and can be used to restore the database if a VM is lost
or purposely destroyed.

By default, db_backup is fired whenever the halt, suspend, or destroy
commands are used. It can also be used from the command line inside
the virtual machine or on the host machine through something like:

`vagrant ssh -c "db_backup"`
Inline provisioning documentation for new behavior

Documents how databases are mapped, not mapped, and backed up
on halt, suspend, and destroy.
Explain vagrant-triggers usage in README steps
Add description of database changes to CHANGELOG
Merge branch 'master' into database

Merges changes to phpMyAdmin instalation
Output a line for each database backed up

Provides some sort of feedback when the script runs so that we know
something happened.
Use Trusty 64 box and remove unneeded PPAs
Specifically install npm
Symlink nodejs as node because Ubuntu sucks sometimes
Check if an SVN upgrade is needed, and if so upgrade all svn repos 5 levels deep from /srv/www
Additional CHANGELOG notes around database (un)mapping
Text changes for DB mapping
Merge pull request #322 from Varying-Vagrant-Vagrants/database

[PR] Only mount shared DB drive if already mounting
Merge pull request #335 from aaroncampbell/trusty64

[PR] Use Trusty 64 box and remove unneeded PPAs