allow prompt for directory to pop a new buffer if needed

When R is started "implicitly" (e.g., with `C-RET` on a line of code in an `R`
buffer not associated with a session), the invocation of R gets wrapped in the
`ess--with-no-pop-to-buffer` macro, which binds the
`display-buffer-ovverriding-action` such that no buffers cannot be displayed.
Although presumably well-intentioned, this has the unfortunate side-effect of
screwing things up for helm users, since when/if `ess` tries to prompt the user
for a directory, helm steps in and tries to display a new buffer in which the
user can make the choice, but its efforts are thwarted by the wrapper.

This gives the `Wrong type argument: window-live-p, nil` error of emacs-ess#1074 because
helm expects to get a (handle to a) buffer but instead gets `nil` when its
attempts are squashed.

This commit fixes things in a hacky way but hopefully sufficiently surgical
manner: it expands the `let` form that wraps `ess-prompt-for-directory` to
rebind `display-buffer-overriding-action` to nil, which undoes (only for the
purposes of prompting for a directory) the attempts of the
`ess--with-no-pop-to-buffer` macro to prevent this kind of behavior.

The thread for emacs-ess#1074 is long and involved, but discussion relevant to this
commit is in [this comment](emacs-ess#1074 (comment)).

lisp/ess-inf.el

@@ -638,7 +638,8 @@ the name of the inferior process (e.g. \"R:1\"), and DIALECT is
 the language dialect (e.g. \"R\")."
   (let ((default-dir (inferior-ess--get-startup-directory)))
     (if ess-ask-for-ess-directory
-        (let ((prompt (format "%s starting project directory? " procname)))
+        (let ((prompt (format "%s starting project directory? " procname))
+              (display-buffer-overriding-action nil)) ; hack to let helm display a buffer
           (ess-prompt-for-directory default-dir prompt))
       default-dir)))