Fix cron issue in WordPress by updating hosts file

Add commands to set the URL you want to use with this 
Vagrant to be 127.0.0.1 in the /etc/hosts file.  This 
allows the webserver to be self-aware and know to look
locally for this domain.  This allows it to call itself
to run wp-cron.  List the domain names you want to use
in DOMAINS.  It checks if that exact record exists in the 
host file and adds it if it does not. 

Future issue to fix:  if you add a new domain to the string,
it will add a new record and leave the old record.  Need to
change this to update the record, or delete the old record...
....or something.  This works fine for now, multiple records 
should not be any problem. 
Merge pull request #7 from TheLastCicada/patch-1

Fix cron issue in WordPress by updating hosts file, thanks @TheLastCicada!
 Add piped comments after every file copy to avoid messy line endings

This is cheap, but I think effective. In certain cases on Windows machines, it's possible that the line endings in the provision.sh get ugly. When the copy commands are run to move different c

By adding a piped message to the end, we make sure that the filename is not what ends the statement. This should avoid any kind of weird filenames being copied into our config directories.
Provision box with dos2unix to help convert line endings if issues arise

We'll need to determine later how best to use this in an automatic fashion.
Add an mu-plugin that can be used with WordPress to alter Cron requests

Something about either our Ubuntu setup or the fact that things are happening in a virtual machine is causing problems with the default 0.01 timeout used by WordPress for cron requests. Cron appears to still work fine, but a notice comes up regarding the fopen error.

This mu-plugins folder can be dropped in to any WordPress wp-content directory and will automatically alter the cron timeout to avoid notices
Timed out again at 0.3, let's try 0.5 for a while
Switch to ln vs cp
Merge remote-tracking branch 'ericmann/master'
Update credits
Watch site configurations with watchr and restart nginx when applicable

If a site configuration is edited while Vagrant start_config_monitor is enabled, restart nginx so that the changes can immediately take effect.
Refactor folder naming to better describe intent

nginx config files now appear in an nginx-config directory rather than hanging out in the general server-conf pile. Other scripts are altered to make use of the new location.
Refactor config locations for php5-fpm to a more descriptive spot

Rather than piling up config files in server-conf, group like files for php5-fpm config into a php5-fpm directory.
Move server-conf to a nicer config directory

This feels nicer and it's my party right now. :)
Refactor location of database files and scripts

Because databases aren't necessarily configs.
Catch up the Vagrantfile with some directory changes

We were pointing to server-conf still even though the directory had been moved to config a while ago.
Better describe (inline) the purpose of the bash_aliases file
Refreshed gitignore to match new file locations
Now that the database directory has been move, it needs to be explicitly mapped
Import script was looking at a hybrid of old/new locations.
Refer to the proper location for the watchr script in bash_aliases