Check out the repository if it is not already present.

[kadamwhite]

This adapts #14 with an alternate approach, using the vcsrepo Puppet module. I've extracted all repo-specific tasks into their own class. That class does these things:

• Add wordpress-develop to the .git/info/exclude file in the parent Chassis repo (this was already done in master, it's just been moved)
• Install Subversion (may not be necessary long-term but felt like a good thing to take care of now)
• Ensure github.com is in the VM's known_hosts file so that GitHub checkouts will work if the user specifies an alternate mirror.
• Check whether there's already a repository checkout in wordpress-develop
• If there is not, clone the develop repository into that directory, and configure the remotes
• Once the repository is set up, create the build folder

Available configuration options:

# You can use synced_folders to map an existing checkout into
# the VM, in which case a new copy will not be pulled down
synced_folders:
    ../path-to-existing-checkout-on-host: /vagrant/wordpress-develop

# The core-dev key holds properties to configure this extension.
# Pertinently to this work, a `mirror` may be specified to add a
# remote to the develop repo checkout.
core:
    mirror: git@github.com:kadamwhite/wordpress-develop.git

[kadamwhite]

The one open issue on this, which I don't think we need to fix now, is that currently the repository class will change the remotes on an existing checkout if you use synced_folders to map it in. I don't know how to work around this because require in Puppet is not behaving as I would have expected it to do.

As noted, I think we can leave this as tech debt for now; I've pinged @rmccue separately about whether there's a better way to ensure the vcsrepo task does not run if the exec is skipped.

[kadamwhite]

Discussion with @rmccue indicates that puppet is not capable of behaving as I want in terms of not mutating existing repositories, which is likely to cause issues if an SVN repository is used in place of Git in the future. However, this feels more robust than #14 so I am going to merge and proceed.