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.
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
Merge branch 'sections'
add magit-with-git-editor-setup

The respective functionality was previously part of
`magit-interactive-rebase'.  Currently this is still the only
function that makes use of this new macro - but that will change.

Add a doc-string to make the macro less confusing.  (That's another
reason why this macro is a good idea; it gives us a place to document
the behaviour.)
improve magit-with-git-editor-setup

In the "non-default name on windows" case use default $GIT_EDITOR
instead of unsetting it.  (If the user bothered to set it she
probably prefers it over the default.)

Use dynamically bound `process-environment' instead of doing an
`unwind-protect' dance.