Factorize comparison and synchronization code

Use the same code for all comparison actions, making sure that
a comparison launches a synchronization instead when there is more
than a single resource to compare (either when the user selected
more than one resource or when the selected resource is part of a
larger logical model).

This created dead code within CompareUtil and GitSynchronizeModel,
which has been removed or made private.

Change-Id: I4ae8abfc4dbe7ed772749afa80743278247585ee

Conflicts:
	org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CompareWithIndexActionHandler.java
	org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitFileDiffViewer.java
Remove unused or useless code

Change-Id: Ib9da57179c6794c22b6b6657a5b87c247b9b2e88
Enable restrained synchronization

GitSynchronizeData can now filter on a set of resources instead
of filtering on a set of containers. This finer-grained filtering
allows us to constrain the scope of synchronization operations.

Change-Id: I1624d0f4b0a24bc141d409a92bc717bf8ebe887c
Only include resources that are part of the data set in synchronize

Workspace synchronization is launched on a given repository (or "a
project of a given repository"). This repository may contain commits
on files that were not imported in the workspace. In such a case, the
GitContainerMapping corresponding to that commit shouldn't create
traversals for the files that are not in the workspace.

Bug: 405772
Change-Id: I824a6a88d701b2787e5c972414b8fd40407e2c8e
Ambiguous parameter naming

What GitFileRevision really expects is a path, not a file name. Most
usages of the constructors already passed in a file path... but the
parameter naming led to a number of clients to use a file name, which
creates FileRevisions with no resolvable path. This fixes all
ambiguous parameter names and usages.

Change-Id: Id597d427555f71a6b4f422acb06a1faf26c796bd