Clarify Vagrant, Virtualbox, and vagrant-hostsupdater versioning and usage

We live in a world of rapidly changing DevOps tools and both Vagrant and Virtualbox can cause their share of issues when we immediately jump to the latest release. However, jumping to the latest release also helps us be aware of issues. These changes are an attempt to clarify some of the version requirements shown in VVV, which aren't always requirements but helpful pointers to current versions. Closes #190

Because this is an overall README change, I also snuck in some additional password instructions around vagrant-hostsupdater. Closes #194
gitignore all files in www/default except for index.php

Rather than explicitly listing the files we don't want added to the repo, ignore all of them and explicitly allow index.php only.

This opens things up a bit more for custom dashboards
Allow for a custom dashboard to replace the vvv.dev default

Uses a file_exists check to load `dashboard-custom.php` if it's available so that a custom dashboard can be provided for VVV

Closes #185
Copy config files instead of linking

In order to start services on init and have them work as expected, we need our custom config files to be available. Provisioning should be used to put these config files into a certain state on the development machine, not necessarily to maintain a constantly linked version. By copying the files instead of linking, we are able to use the config files before the drives are mapped later in the provisioning process and the services are able to start properly.
Introduce a vvv-start.conf file for /etc/init/

This manages the starting of services on runlevels 2345.

Many, many thanks to @danielbachhuber for https://github.com/humanmade/Salty-WordPress/commit/9d7a90cfc18566b07c17205fb46ca455203eaf91 on Salty WordPress. This causes some hacky sleeping to happen until the persistent MySQL data has been mounted properly inside the VM.
Copy individual nginx site configs rather than linking

Still some work to do on this as existing setups may completely blow up when we remove linked files before then copying the non-existent files. It'd be nice to find a way to unlink things first. Hrm. We're probably going to need to recommend a vagrant destroy for this update. We'll see.
Don't remove things just yet, that could destroy good config files.
s/themese/themes/
update phpmyadmin to 4.0.9 + use multi-language package
Find and exec vvv-init.sh before finding vvv-nginx.conf

The vvv-init.sh script may in fact generate vvv-nginx.conf files on the fly.
Inline auto-site-setup so init-generated vvv-hosts can be found
Merge pull request #198 from cfoellmann/update/phpmyadmin

update phpmyadmin to 4.0.9 + use multi-language package
Update contributors list
Remove unused dev.testing.com.conf

Looks like this was added by me way back when during a moment when I accidently added all of my custom domains. Good time to ditch it as it helps me test this new rsync line. :)
Use rsync to copy individual site configs from nginx-config/sites
If our custom-sites directory does not yet exist, exist it.
Better grouping and documentation of config files
Copy dotfiles and bin files rather than symlinking

Another step toward a clean vagrant up without provisioning
Unlink previously symlinked files before copying

This sets things up to work on future uses of halt/up without requiring a full destroy. As long as `vagrant provision` is run, no destroy is needed.

Note that it doesn't make sense to keep this here forever. At some point we'll just have to recommend a full `vagrant destroy` to sync back up with the repo.
Formatting is great!

A nice output is nice sometimes.