Fix fold file open/delete race

This fixes the race between a fold getting an epoch and opening the
files in the Bitcask directory.  If between those two actions a file
needed for that snapshot is deleted by a merge, the fold will return
incorrect data.

A fold will now fetch the list of files that it needs to open and the
epoch to use to access a snapshot of data with one operation. It will
then try to open the files, and if it fails try again with a new set of
files and a new epoch.

One question remains open: Now if someone deletes a file from under
Bitcask, the fold will fail indefinitely. Before, it would eventually
proceed and return whatever data is still left. Obviously we'll need to
let it do something similar, falling back to returning partial data.
Fix for Dialyzer complaints related to change in keydir_info() spec
Avoid retrying to open missing files on folds

The fix to the fold open/delete file race made folds fail for a long
time if a file was deleted from the cask. This fix makes it so that we
detect that and avoid trying to re-open a file that has gone truly
missing again and again.
Add interfere_with_pulse_test_only() to aid PULSE in finding issue #174's race
Fix Dialyzer warning
Avoid creating file stat on deleted files

Because now we have code appending tombstones to potentially deleted files,
file stats entries were occasionally created on already deleted files.
Now the update_fstats call has a flag to signal when it is OK to create
a file stat entry if it doesn't exist already.
Raise fork_results() timeout 1000x to avoid false timeout errors from commit ee05a89f4
Merge pull request #175 from basho/bugfix/fold-open-delete-race

Bugfix/fold open delete race

Reviewed-by: slfritchie