Bugfix: read-only folder iterator open across close & re-open read-write

It's possible that this crazy sequence of events has happened:

  1. Proc A opens cask in read-write mode
  2. Proc B opens cask in read-only mode
  3. Proc B starts a fold
  4. Proc A causes enough mutations to freeze the keydir.
  4b. Proc A deletes key K.
  5. Proc A closes the cask.
  6. Proc A re-opens the cask in read-write mode.
  7. Proc A starts a fold.
  8. Proc B finishes its fold, releases itr, and closes.
  9. Proc A visits key K but doesn't see the delete
     from step 4b because the keydir was originally
     frozen way back early in step 4 and has since
     never been unfrozen.

Add a new EUnit test, freeze_close_reopen_test() to test the
above scenario.

The fix adds a flag to keydir_remove(): NewestDeleteB::boolean().
The purpose of this argument is the same as keydir_put()'s
NewestPutB::boolean(): to signal that the change is something that
should always be visible to a read-write user of the cask.
The patch is very slightly more cluttered by my adding the new arg
in the middle of the optional/conditional arg list; my intent
was to use the same conditional arg order as keydir_put().

Also, fix a bug where the order of calling proxy_kd_entry_at_time()
and is_tombstone() inside find_keydir_entry() was in the wrong order.

Fix the fold_visits_frozen_test() EUnit test to reflect the new
semantics of keydir changes made while a read-only folder is in
progress.

I decided to leave in a whole bunch of ?DEBUG() macros in bitcask.erl.
They're just too damn useful to yank out, wait a week/month, then
realize that I need to put them back in.  The macro's use means that
they're completely removed by the preprocessor when not debugging.

There are a few whitespace-only changes, sorry for the patch clutter,
but I wanted to tidy those things.

Add a preprocessor-adjusted display_if_pulse() function for extra
messages when the bitcask_pulse property is checked.