Drop optimization to avoid intermediate variable in some cases

[okamsn]

See also #204.

Needing to know the exact behavior of each command to remember whether it
behaves differently is too much of a burden to be practical. If one were to add
an iter-opt special macro argument, that would only move the burden to needing
to remember when to use iter-opt.

As mention in #204, using iter-opt requires the user to:

1. Read the documentation to know that a command supports it
2. Always remember that the command supports it while using the macro
3. Always remember how it affects the command while using it

all for a slight gain in speed and marginally less typing.

For those reasons, instead of adding iter-opt, it is better to remove these
few optimized behaviors in favor of more standard behavior. As noted in #204,
instead of writing

;; => (5 (1 2 3 4))
(loopy (iter-opt (numbers i))
       (list elem '(1 2 3 4))
       (numbers i :from 1 :to 10)
       (collect i)
       (finally-return i loopy-result))

one could instead write

;; => (5 (1 2 3 4))
(loopy (with (i 1))
       (list elem '(1 2 3 4))
       (while (<= i 10))
       (collect i)
       (set i (1+ i))
       (finally-return i loopy-result))

which is basically the same length while requiring less knowledge of each
optimized iteration command's internals.

There are already cases where Loopy is not hyper-optimized, such as explicit
accumulation variables. However, there, the behavior of accum-opt is much
less of a burden to remember, because it affects every accumulation command
in the same way. There are no special cases to remember.

For these optimizations, it is the case that Loopy's flexibility and consistency has a small cost, but they are not the only case of that (consider how cl-loop moves some variable setting to and expressions while we settle for catch and throw) and we do not question the value of consistency and predictability in those cases.