Dialyzer fixes and turn on warn_untyped_record & warnings_as_errors
Fix test compliation
Fix a bad refactor
Add sibling->regular entry conversion sweeper

This fix is just a translated version of Scott's change here:
1563feb3e64c85a5498e992090e99fb4d1825555

To allow Bitcask to handle multiple iterators, the keydir was modified
to allow multiple versions of an entry. That way multiple iterators
could see different snapshots of the data as it was modified.
Removing versions of entries that were no longer needed only happened on
access to those entries, so that potentially a lot of unneeded memory
could stay around for a long time. This adds a mechanism to reclaim that
memory little by little. On each get/put/delete operation, the sweeper
spends a bounded amount of time removing stale siblings.
The amortization mechanism attempts to limit itself to less than
1 msec of additional latency for any get/put/delete call, but
it doesn't always stay strictly under that limit when
you're freeing hundreds of megabytes of data.
Changed cuttlefish rhs subs to use $ syntax
Merge pull request #141 from basho/jd-comments-rhs

Changed cuttlefish rhs subs to use $ syntax
Simplify find entry snapshot use

The find entry function's semantics were a bit trippy.
If passed in MAX_TIME, it would still never access entries from the
pending hash. It could also get confused if it found something in the
regular hash, but not corresponding to the snapshot time given.
This simplifies it so that it only indicates found if a value for the
given snapshot was found. The value could be a tombstone.
If passed a large enough snapshot time, it could find entries in the
pending hash.

To keep old semantics, iteration should never take into account values
in the pending hash, which may change during the iteration.
To do that with the new clean find operation, the folds will use a read
time capped at the time the pending hash was created. This should
translate well to the upcoming changes that use a time independent epoch
instead, while being compatible with the old fold on frozen semantics.
Removing rw flag from get

Further cleaning up the get path. This flag was simply working around
some of the semantic issues with gets that this branch is fixing.
Merge pull request #143 from basho/bugfix/correct-snapshot-on-find

Simplify find entry snapshot use
make sure that we always have enough license to finish the test we've
asked to start.
Merge pull request #145 from basho/ensure-licensure

Ensure licensure for long pulse tests.
- pull in multifold regression test from #134
- pull in more aggressive pulse tunings from #128
- remove all test sleeps related to old 1 second timestamps, so that
  things will break if old code is retained.
move away from timestamps to a per-run epoch counter for all keydir
mutations and iterations.  this adds 8 bytes per key, but it's better
to use slightly more memory than to be vulnerable to clock skews, and
gives us hard freezing boundaries to make folds work as they have
done traditionally.
Merge pull request #140 from basho/pevm-keydir-epoch

move from timestamps to epochs for folding and siblings
add failing unit test that exercises the issue
remove debugging print, de-race the unit test.
it's possible, (via kill, and possibly other methods) to hang the
keydir in a frozen state forever, which basically stops all folding
and guarantees memory growth of at least 2x over time.  This change
factors out the cleanup and pending merge behaviors and adds another
point where it can be called, at handle GC time, which should have
better guarantees of happening.
Fix race with concurrent merges and deletes

This fix is a remake of Scott Fritchie's slf-tombstone-management
branch. It builds on heavy cleanup of the get functions that created a
lot of edges cases the branch worked around, as well as the introduction
of epochs by Evan that fixed problems with folds not viewing a stable
snapshot after the multifold support was added, as there were edge cases
around the use of timestamps.  The retry code in delete was refactored
into the put method, and the tombstone2 was removed as it could not
solve the merge/delete race by itself while creating incompatible data
files.

* A delete in the writer process may race with a merge writing a value
  for the same key on a file with id greater than the current write file.
  Re-opening the cask would end up loading the merged value and forgetting
  the delete. The delete path will now detect the race and retry the
  tombstone write on a file with id greater than the merge file until it
  prevails.
* A partial merge could end up removing the tombstone for a key that
  still has a value in one of the unmerged files. tombstones just can not
  be dropped during a partial merge without knowing that all previous
  versions have disappeared too, so we avoid it. This may create more
  garbage on disk than previous versions, but it's safer. We should have a
  way to force a full merge.
  kind of tombstone that contains a pointer to the value it is replacing
  has been added.
* Change order of scan & fold: now oldest -> youngest.
* Add un-write last used when writing to a file and then finding a
  conflict when updating the keydir. The write is tried at a higher file
  and the old write is undone. Used in the merge/delete race fix.
* Avoid getting time in C land, passing it from Erlang instead. Now time
  in tests can be completely faked.
* Adjust command frequency weightings for PULSE model to find problems
  like this merge/delete race.
* Avoid storing tombstones in the keydir when possible. For this,
  hintfile records store a flag in the offset field to indicate value is
  a tombstone.
* For testing purposes, fold() and fold_keys() are extended with
  another argument to expose the presence of keydir tombstones.
* And add option to make those compiler errors
Fix merge not correcting race on tombstone write

If a merge writes a tombstone, it needs to detect whether a new value
was put for that key at the same time and avoid that tombstone
overriding it on disk.

As part of this, removing use of merge start time or epoch. Merge logic
should see latest entries in the keydir. I'm not sure why it bothered
checking timestamps on files and the merge timestamp. I imagine that was
able to hide a pulse failure in the past, but does not seem correct.
Fix PULSE shrinking control

From Ulf Norell:

    One reason you might have some problem with shrinking (but which should be
    unrelated to the issue at hand) is this code:

      P = ?FORALL(...),
      ?SHRINK(P, [?ALWAYS(3, P)]).

    When you wrap ?ALWAYS on the outside you'll get a fresh command sequence
    for each repetition, so what will (most likely) happen in this case is that
    the shrinking step from P to ?ALWAYS(3, P) fails and shrinking proceeds
    just with P. The right way to do this is to use the shrinking parameter:

      ?FORALL(Cmds, commands(?MODULE),
      ?LET(Shrinking, parameter(shrinking, false),
      ?ALWAYS(if Shrinking -> 3; true -> 1 end,
      ?FORALL(Seed, pulse:seed(),
        ...
      )))).

    Note how the ?ALWAYS is placed between the command generator and the seed
    generator. That way each repetition will use the same command sequence but
    a different seed.