Fix up spaces vs. tabs.
Change the way we recommend and report the ops per sample, or -B switch value.

 1. Emit the actual (well, average) count of ops per batch as reported by the
    benchmark (some benchmarks do things in multiples of 10, others have a
    minimum or a maximum, etc.)

 2. Drop the warning for too few ops per sample, as we really only want to
    make sure the sample time is long enough (1ms) to be worth timing, and
    short enough that we don't collect too many samples.

 3. The reported recommendation is now always 1, if the time it takes to run a
    benchmark once is greater than or equal to 1ms, or the value: 1ms / mean
    ops per sample.

Also, fix up the reported stats output so that the numbers line up better.
Rework to measure time it takes to hop through specified memory size, 16 pointers at a time; the -B value specifies how many times to go through the memory size.
A bit of cleanup before further changes:
 * Remove unnecessary parentheses
 * Reinitialize the fd array in finibatch for consistency
 * Double check that we actually have an allocated array
 * Use snprintf where possible
 * Empty arguments declare with void
 * Use a tab character in usage string to match framework
Update usage output to reflect previously added -R and -O parameters, updating the README as well.
Record the default, or initial thread, when running the suite. This will help later when we only want one of the threads participating in the benchmark to do something.
Clean up whitespace usage.
Rework to enable dynamic sizing of the number of ops to run per sample.

This change obviates the need for a suitable value for -B so that a sufficient
number of samples are taken in the time allotted.

Typically running a suite of benchmarks for an unbounded amount of time, or
for a bounded amount of time with too few samples, in undesirable. By
dynamically calculating the number of ops to run per sample, the framework can
run the benchmark in a given time period while still collecting enough samples
to have statistical significance. In the past, to do this one had to run the
benchmark first, see if it gather enough samples or ran too long and then
adjust -B accordingly. Now, by specifying both the required minimum number of
samples and the minimum required amount of time to run, the framework can
gather enough samples to meet those constraints.

For benchmarks that can handle changing values for lm_optB (-B), the harness
will make an initial calculation for lm_optB (using the default value of -I),
and take a measurement. It will then figure out the ops per sample from that
run, and invoke the next iteration with a new value for lm_optB. It will
repeat that for the duration of the benchmark using the calculated mean from
all the runs made to date.

Most benchmarks can trivially handle dynamic changes to -B (really, lm_optB),
but for those that cannot, they explicitly disable the feature during their
initialization (lm_dynamic_optB = 0). The suite files contain explicit values
for -B, as measured from a reference system (an HP DL380 G7 Nahalem 2.93 Ghz,
2 socket, 4 cores per socket, HT enable, 24 GB of memory).

The formula for -B, when not specified on the command line, dynamic mode or
not is:

    if ops_per_sample > 1ms
        -B = 1
    else
        -B = 1ms / ops_per_sample

The ops_per_sample is taken either from the value of -I, or the default value
of -I (500us, changed from 1us for a better initial value of -B for longer
running benchmarks).

This tries to target a timing run of 1ms for benchmark(), resulting in a
target of 1,000 samples per second that the benchmark runs. Almost all
microbenchmarks have an ops per sample less than 100ms, such that a healthy
number of samples (>= 100) can be collected in 10 seconds.

Specific changes that were made include:

    * Removal of lm_defB, since we no longer need to specify a default when
      the parameter is not present

    * Removal of lm_nsecs_per_op since it does not seem to make sense to
      record a number in a benchmark that is specific to a result from a
      platform, and because we can now dynamically arrive at a good value
      during the run of the benchmark

    * Removal of explicit -B parameters from all suite files for benchmarks
      that can handle dynamic changes to lm_optB

    * Added the lm_default_thread cell to help facilitate which thread changes
      lm_optB and allow benchmarks to take advantage of that as well

    * Convert open.c, mmap.c and munmap.c to handle dynamic changes to lm_optB

    * The minimum data set size has been bumped from 2,000 to 20,000 to
      accommodate the number of samples generated from tests that have an ops
      per sample under 1ms

    * Updated the -B values for the benchmarks that can't handle dynamic -B

    * Update the README to note the new behavior and updated default options

    * Record the benchmarks in TODO could be converted to handle dynamic -B

BUG FIX:

    * The stored value of the data set size was incorrectly multiplied by the
      number of participants in the barrier