magit-git-executable: except on windows, use just the name

Since f0186c88732e543d9487082405685fa0a2688b70 `magit-git-executable'
was set to the full path to the executable, which becomes problematic
when connecting to a remote repository using Tramp and the executable
is not installed in the identical location on that system.

On Windows keep using the full path, because here multiple "git.***"
are installed and it makes a big difference which is used.  I would
much rather have a handful of Windows users report that they cannot
use Magit remotely than to have many more users complain that "Magit
is nice, but soooooooo slow on Windows".

We could use different variable for local and tramp Git, I suppose.
But the proper way of testing that is `file-remote-p', and that is
to expensive to run over and over again.  And I don't like caching.
deal with yet another way Emacs can be installed on OS X
fix 973a5ab06a55e0b8779be91968d32a92851b6f68
magit-svn-find-rev: fix issue #1404

`magit-show-commit' expects a string not a section.
try harder to locate a suitable emacsclient executable

Improve how the default value of `magit-emacsclient-executable' is
determined.  If we fail to do so, show a warning.

We determine whether an emacsclient executable is compatible with the
current Emacs instance by comparing its version with `emacs-version'.
The versions don't have to match exactly, but at least the major part
has to do so.

This commit changes how an executable's version is determined.
Previously we simply used the version suffix of the executable.
Unfortunately when Emacs is installed manually, then the emacsclient
executable usually does not have a version suffix, and so we did fall
back to the suffix-less executable which comes first on `exec-path',
which is a lottery.

Now we use `emacsclient --version' to determine the version, and the
order in which version-suffix-less emacsclient executable appear on
the `exec-path' therefor no longer matters.
Merge branch 'locate-emacsclient'
fix last commit