Remove old, nonsensical inline documentation from a time past
Don't provide a persistent database after `vagrant destroy`

I've reversed on this a bit. We should enforce good workflow rather than trying to account for absolute convenience, especially when the persistence of this database can cause issues.

Use `vagrant halt` or `vagrant suspend` to avoid losing DB changes.
Use `vagrant destroy` to wipe the entire DB clean.

We'll want to provide some default DB setup files for when it is wiped clean.
Add documentation for intention of the wsuwp-prod SLS file
Map persistent www/ directory to /var/www/ in development environment

Rather than relying on a pseudo deployment script in our local development environment from rsync, we should just map the drive with persistent data.

This does introduce a really hacky scenario. By default, there is no www-data user or group in the CentOS box that we're using, so we don't have the option to mount /var/www before provisioning starts unless we're okay with the Vagrant user. We allow that to happen and then unmount and remount the drive as www-data once the primary provisioning script runs.

Now that I better understand the issue, there's a chance that we can move the unmount/mount into the wsuwp-dev SLS for a cleaner Vagrantfile.