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
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.
Cleanup mysql configuration area to match the rest of provisioning
Update CHANGELOG to highlight big stuff from 1.0-working so far
Merge pull request #196 from 10up/148-vagrant-up

Start required services on vagrant up

Happily, happily, happily closes #148
add www/default/assets/* to tracked files
domain changes and provision.sh changes