Refactor populate to return working directoryIn an attempt to implement locking of the git clone directory ingradle/gradle-native#146, we realized that the directory lockingmechanism writes a lock file into the directory being locked. Thatlock file prevents jGit from cloning into the directory because itexpects directories to be empty when they are the target of a cloneoperation.This change moves the responsibility for calculating the path to theworking directory into the VersionControlSystem and provides thepopulate method with a parent directory which can be the target oflocking.Part of gradle/gradle-native#146
Move more logic into the TemporaryGitRepository fixtureWe don't have to expose the whole fine-grained API used in the JGitunittests to meet our needs for testig Gradle code. This narrowerAPI allows us to reuse more logic.
Spike a GitVersionControlSystemThis spike just shows as a proof of concept how we can genericallyapproach version control system integration. This spike demonstrates: * The use of a `VersionControlSpec` to define the url of the remote repository. * The use of a `VersionControlSystem` as the high-level abstraction for all version control systems. * A *very* rudimentary implementation of the `populate` method for a `GitVersionControlSystem` * An initial fixture for testing our Git integration.The spike does not yet cover: * How to get an instance of the correct type of version control system based on the type of the version control spec that was provided. But, we'll probably use some version control system registry. * Sophisticated handling for many common scenarios when populating a working directory from a repository. * Working directory exists and has correct remote. * Working directory exists but is not a git repository. * Working directory exists but has other remote. * Multiple working directories for the same remote. * Poorly formed user-input.Related to https://github.com/gradle/gradle-native/issues/107