Replace unistd functions with cross platform counterparts

[eelstork]

Via unistd.h, caffe uses a handful of functions not readily available on non-Unix systems; boost is cross platform and affords more concise, more readable implementations (notably, with reference to MakeTempFilename and MakeTempDir).
To support this, CMake and Make builds are updated to link against boost_filesystem.

[eelstork]

Thanks to @flx42 for suggesting a truly cross platform temp dir.

[ronghanghu]

LGTM :) Replacing unistd.h with boost should make it easier to build caffe across platforms for community windows ports.

[flx42]

You have another place where you are using "/tmp", I guess you could also remove it and use boost too.

[eelstork]

@ronghanghu thanks for looking at this.
@flx42 fixing.

[ronghanghu]

I plan to merge this PR, if other people don't object.

[shelhamer]

👍

[bhack]

Are we not ready for tmpfile et al.?

[eelstork]

@bhack I appreciate difficulties running Boost on iOS and Android. In the meantime I'm not sure that C++11 is a silver bullet for cross-platform support. With a little more refactoring we'll be able to handle this.

[futurely]

Did this solve the problem of potential race condition #1063?

[futurely]

It seems not. #3324

[ronghanghu]

Oh, I didn't notice the race condition in #1063. My bad. This is probably causing directory creation to fail in #3324?

It seems that both versions (old and new) have potential race conditions, so it is a bit unclear to me why #3324 starts to appear.

[futurely]

The easiest solution is to add a macro USE_BOOST_FILESYSTEM and keep both versions.

[eelstork]

@futurely I think we are going to do this the hard way.
@ronghanghu if I understand correctly #3324 isn't a regression caused by this PR, but we're seeing significantly more occurrences since merging this?

[ronghanghu]

I'm not sure if there is more occurrence of #3324 after this PR. Seems tricky to do a perfect fix to the race here. At this point the function is only used in test cases so I guess the race condition shouldn't affect too much.

[eelstork]

@ronghanghu I've seen a couple more. I think it's worth fixing.