Improve GitContextMock

[hohwille]

Task summary

As a mock for GitContext we have GitContextMock.
However, this was rather a hack than a solution.
This story should create a reasonable mock implementation.
The clone operation should do the following:

• Create the given repository directory including a .git subfolder.
• A file HEAD gets created in the .git folder containing: ref: refs/head/«branch» where «branch» is the branch property from the GitUrl.
• A file FETCH_HEAD gets created in the .git folder containing the hashCode() of the GitUrl.
• Inside the .git subfolder a config file is created with our IniFile support. It should contain at least the following entry:

[remote "origin"]
        url = «git-url-provided-as-arg»

Operations like retrieveGitUrl and determineCurrentBranchshould return back the information stored by clone from the according files.
The operation ``determineRemotecan first be hardcoded to returnorigin`. We can still make this more complex when needed.

A new method will be added to GitContextMock:

void addChanges(Path repository, GitCommit... commits)`

Here GitCommit is a wrapper for a List of GitChange.
And a GitChange has at least the two properties:

• Path content (path to the file or directory to copy to target to apply the change)
• Path target (relative path in the repository)

So to apply a GitChange we simply copy content using FileAccess to the target path resolved in the repository path.
And to apply a GitCommit we simply apply all contained GitChanges.
The method addchanges simply puts all given GitCommit objects to a list or queue of pending commits.

The operations like fetch and pull will then be implemented according to the pending commits.
If there are no pending commits, they will do nothing.
A fetch will update FETCH_HEAD to the hashCode() of the latest pending commit (not the first one to apply but the last one in the "queue").
A pull will apply all changes from the pending commits in order to the given repository and also update the HEAD.

Our tests using GitContextMock can then be reworked and improved to make use of the new features.
Also we can properly test features like ide upgrade or the check if update is available, etc.

Additional context

This is already quite complex.
Let us not over-engineer it further. So operations like reset can initially do nothing.
We could still later keep a .git/backup folder that we maintain by GitContextMock to also implement reset, etc. but IMHO this is not needed in near future.