Test for a specified pillar db_user before adding the user

Over time we should probably make this a bit smarter.
Add initial opcache config installed by default

We'll have this available as a managed config file for provisioning as things like memory consumption will change from environment to environment
Set default opcache memory limit to 256MB
Add opcache.ini to the webserver state file
Ensure a directory is provided for each expected nginx host

Sets recursive permissions at this time as well to www-data, 644, 755
Ensure wp-content directories are available after provisioning for each site
Ensure a `wordpress` directory exists on each site

Permissions are set here to be non writeable, which 'should' work for us because our wp-content directory exists one directory up.
Add a wordpress.sls state file for WordPress projects
Move database user creation to wordpress.sls
Provide intial stable WordPress release for each site.

We'll deploy upgrades to each site through other means. This is for initial setup only.
Fix top.sls syntax error
Remove forced file permissions for newly created directories

On production, we'll likely run a chmod command for everything as provisioning finishes. The VM doesn't like permission changes for local development.
Use mkdir rather than the file.directory states

file.directory was slowing down provisioning quite a bit. This simplifies things and just uses mkdir instead
Use mkdir -p to silently fail if a directory exists
Rely on mkdir -p to automatically create wp-content

We don't need an explicit declaration, as the -p flag makes this happen in our other mkdir usages
Download one copy of WordPress stable to be used on all installs
Modify previous WordPress download to copy over temp zip file instead
Ensure a site directory is available as well before creating additional directories
Provide wp-config.php via a jinja template for each site
Can't enforce file permissions on the VB shared drive

We'll need to do a production only command for this after the fact