use the semantically best conditional

Or "don't use if when there is no ELSE".

This is about semantics not just about aesthetics.

* (if COND (progn FORM...))   =>  (when COND FORM...)
* (if COND THEN)              =>  (when COND THEN)
* (if (not COND) THEN)        =>  (unless COND THEN)
* (list (if COND THEN) ...)   =>  (list (and COND THEN) ...)
* (and (if COND THEN) ...)    =>  (and (and COND THEN) ...)
* (or (if COND THEN) ...)     =>  (or (and COND THEN) ...)
* (if ... (if ... (if ...)))  =>  (cond ...)
* (if COND (progn THEN) ELSE) =>  (if COND THEN ELSE)
* (if COND (progn THEN...) ELSE...)
  =>  (cond ((COND FORM) THEN...) (t ELSE...))  ; not always
* (or COND (error ...)) (if COND THEN ELSE)
  =>  (cond (COND (error ...)) (COND THEN) (t ELSE))
* (if COND (FN A B) (FN A C))
  =>  (FN A (if COND B C))
* (when CONDA (when CONDB THEN))
  =>  (when (and CONDA CONDB) THEN)
* (cond ... (t (when COND THEN)))
  =>  (cond ... (COND THEN))

Please not that I have not inspected every single conditional.
Instead, I have "only" looked at matches for "(if".  In very few
cases I have not switched to the best conditional because the
surrounding code actually needs more extensive cleanup.

Also I have kept:

* (if COND nil ELSE)
* (if COND THEN nil)

when I felt doing so actually makes it easier to the reader.

However the latter was often used as the last form in functions, and
since in elisp functions always return a value I have in most cases come
to the conclusion that (when|unless COND RETURN-VALUE) is just as easy
to understand.  But when it is not immediately obvious that the return
value of a function is significant I have kept the old form with the nil
THEN or ELSE form.

There is never a good time to do this kind of change.  But now is a less
bad time because I have also moved code around during the past month, so
tools like git-blame will have troubles looking furthur into the past
anyway.

Also see #663.
Makefile: removed install-loaddefs target.

There is no rule for this target and it causes an error when invoking
"make install". loaddefs are installed by the "install-lisp" target so
there is no need for it anyway.
Makefile: use install-info to install info files by default.

install-info is available in most linux distributions while
ginstall-info is not.
Merge pull request #730 from bastianbeischer/makefile_fixes

Fixes to make install rules
Don't use an unqualified title for the unstaged changes

The title of the unstaged changes section was changed to be dynamic in
c0d6281d, but no explanation is given for the change.

Deviating from the standard git nomenclature should only be done when
there is a clear win for the user. In this specific case the change in
wording creates an unwanted ambiguity in the interface.

Fixes #727
Remove unneeded parameter from unstaged-changes inserter
Fix "git reset" failing with identical file/tree names

"git reset foo" fails, if there is a file *and* a tree named "foo" in
the current repository.  Hence, pass "--" at appropriate places to
unambiguously determine the type of argument given to "git reset".
Merge pull request #735 from lunaryorn/unambiguous-git-reset

Fix "git reset" failing with identical file/tree names
Merge branch 'conditionals'
magit-stash{,-index}: cosmetics
shorten long lines
use cl-mapcan instead of (delete nil (mapcar ...))
Merge branch 'cleanup'
move magit-grep into section "Acting (3)"

Also rename toplevel section "Extensions" to "Magit Extensions"
and move it into section "Miscellaneous".
sanitize interactive magit-grep
make "Submoduling" a subsection of "Acting (3)"
move magit-interactive-rebase into "Rebase" section
move magit-interactive-resolve into subsection of "Acting (3)"
make "External Tools" a subsection of "Miscellaneous"
fix typo in section heading