The project folder was originally configured to use 998 as the user and
primary group IDs in ceb733c, where 998
is the ID of the servidor user/group... or was on my machine.

Turns out, that's not always the case--in #274 the servidor user got a
different UID/GID, resulting in a failed install due to permissions.

We can't set the owner/group to `servidor` until it exists, so this adds
an inline shell provisioner specifically for creating the user. To run
that before the installer though, we need a 3-step process. The first is
`vagrant up` because you can't `vagrant provision` before the VM is
created. Although `up` will fail to mount shares, we can then provision
the user before restarting the VM (to get shares back) to run install.

The process is long-winded and composer *still* has permission issues,
but this at least solves the race condition with the servidor user.

Due to a bug in Virtualbox, there is a race condition when using vboxsf
for the synced folders where Composer extracts and deletes files faster
than Virtualbox can keep them in sync.

Adding the `--perfer-source` option to composer will stop it using the
compressed distribution packages to avoid the extract/delete issue.

Also adds a separate ./storage mount with the www-data group to fix
an issue with writing the Laravel error log.

**Related:**
* https://www.virtualbox.org/ticket/18776
* laravel/homestead#1240 (comment)

Turns out running composer with --prefer-source is slooooooow. we're
talking like... 30 minutes slow. It's normally done in less than two.

This adds a check in the makefile to see if we have composer available,
and if so we'll run it before creating the Vagrant VM which will cut out
much of the process when it comes to composer install in the installer.

No need to make any changes in the installer itself as composer is smart
enough that it will only install any packages if they're different to
what was already installed 5 minutes previous. That's only likely to
happen if someone has a custom composer config that changes things.

Since we're already installing composer packages during env setup, we
may as well install npm dependencies and compile the frontend assets
too. While we're at it, the readme also gets a bit of an overhaul.

The version of `sed` available on OSX is an outdated piece of garbage,
like most system utilities in the apple world. It doesn't like the
`{/.../,+1d}` expression to "find this line and delete it and the one
after", but since the lines in question are the ones that include the
install scripts, we kinda *need* to remove them.

Ironic that fixing this the easy way would create an Infinite Loop...

I'm not about to turn the sed command into something 20 lines long just
to satisfy OSX, so instead we check for gnu-sed before falling back to
sed-proper. If it turns out we're using `sed` and uname == Darwin, that
means they didn't brew install gnu-sed and thus we abort compilation.