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.
Simplify VersionControlSpec interfaceSpecifically: * Remove the `url` getter and setter * Extend `Describable`This will allow us to make fewer assumptions what it means to be aversion contorl repository. Maybe some of them won't have locationassociated with them.
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