Make the recursive version of mkdir ignore EEXIST errors

To summarize the issue:

Our implementation of mkdir in the recursive case checks if a directory exists
and if it does not, attempts to create it.  Coverity flagged this as a TOCTOU
(time of check, time of use) vulnerability, which basically means that in the
space between the check and when we attempt to create the directory, the
directory may have been created.  In the case where it was created by an
attacker, the directory may point somewhere completely unsafe.  It is not
currently possible to lock a file or directory that has not been created yet, so
there is no way around this error, and our detection of this error depends on it
being created only during that brief window between checking its existence and
attempting to create it - if the parent directories did not exist at the start
of the recursive mkdir call and came into being just before we checked their
existence, we would not notice.  Since we cannot guarantee to notice directory
creation outside of ourselves, we will drop any time we do notice this on the
floor.

Personally, I think we should warn if we do happen to detect it.  But I have
been overruled, and the behavior is consistent with the command mkdir -p.  It
also has the nice side effect of a clearer error message in the case where we
attempt to create a/b/c when b is not a directory (if such a race had occurred).

Updated a test to guarantee we don't warn on EEXIST in the recursive case.  And
updated the mkdir interface comment.
Merge pull request #1068 from lydia-duncan/mkdirKerfuffle

Make the recursive version of mkdir ignore EEXIST errors
[reviewed by greg]

To summarize the issue:

Our implementation of mkdir in the recursive case checks if a directory exists
and if it does not, attempts to create it. Coverity flagged this as a TOCTOU
(time of check, time of use) vulnerability, which basically means that in the
space between the check and when we attempt to create the directory, the
directory may have been created. In the case where it was created by an
attacker, the directory may point somewhere completely unsafe. It is not
currently possible to lock a file or directory that has not been created yet, so
there is no way around this error, and our detection of this error depends on it
being created only during that brief window between checking its existence and
attempting to create it - if the parent directories did not exist at the start
of the recursive mkdir call and came into being just before we checked their
existence, we would not notice. Since we cannot guarantee to notice directory
creation outside of ourselves, we will drop any time we do notice this on the
floor.

Personally, I think we should warn if we do happen to detect it. But I have
been overruled, and the behavior is consistent with the command mkdir -p. It
also has the nice side effect of a clearer error message in the case where we
attempt to create a/b/c when b is not a directory (if such a race had occurred).

Updated a test to guarantee we don't warn on EEXIST in the recursive case. And
updated the mkdir interface comment.

Those curious about the discussion may view
#402