bug#18175: files.el: use mapc in (mapcar 'switch-to-buffer ...)

[Drew Adams <drew.adams@oracle.com>]

> The docstring for the latter reads:
> … If BUFFER-OR-NAME is a buffer, return it as given.
> And I see no reason for a buffer /name/ to ever appear in the
> lists returned from find-file-noselect.

Yes, of course not.  It needs to return a list of buffers. That's why I
wrote that we need to "make sure that the list of buffers returned is
the same in all cases as what is returned today." ^^^^^^^

>  > I'm guessing that that can make a difference only if the intended
>  > buffer cannot be switched to (an error is raised).  And in that case
>  > I'm guessing that the error raised would be handled correctly by
>  > `find-file*'.  (I have not checked.)
> 
> 	As there’re no condition-case forms around switch-to-buffer
> 	calls in find-file et al. – no such error will be handled in any
> 	special way, and will just be signalled to the user as usual.

That all I meant by handled (treated) by `find-file*', not that
there is a `condition-case' with a handler.  The point is that the
behavior should remain the same; that's all.  If it does, fine.

>  > You might also want to check to be sure that the effect on what
>  > `buffer-list' returns (after the calls to `switch-buffer*') remains
>  > the same.
> 
> 	AIUI, the buffer-list result depends solely on the order of
> 	calls to switch-to-buffer, which is /not/ changed in any way.
> 
>  > The calls to `switch-to-buffer*' here do not use non-nil NORECORD, so
>  > that at least can be ignored.  But maybe take a look, to make sure.
>  > Some commands and other functions depend on the buffer order in
>  > `buffer-list', so this too should not be altered by your proposed
>  > change.

Thanks for looking at and testing these things.