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.
Merge branch 'conditionals'