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.
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.
Merge branch 'git-editor'
fix typos in documentation