Checkpoint progress on port to js shell.

(Most of it was spent making a nicer interface for 2D arrays backed by
a 1D array, which I might have to rip out anyway.)
Checkpoint state at end of day.
Fixed a couple of bugs.
Fixed more bugs in cutVertical; renamed cut* functions to cut*BW; added shrinkBW.

Example usages:

    js> tinyImage.print()
          .        ^
          .       ^^^
     @    .        ^
    @@@   .            %
     @

    js> [tinyImage.width, tinyImage.height]
    [20, 5]

    js> tinyImage.shrinkBW(11,5).print()
        '   ^
        '  ^^^
     @  '   ^
    @@@ '     %
     @

For a bigger example, check out: bigImage.shrinkBW(100,25).print()
Remove Array.build and references to it.
Add some new routines: medium image, random generator, timed shrink.
Added mode parameter to all processing functions (even non-ParArr ones).

This way, one can compare par and sequential by running like so:

    js> bigImage.timedShrinkBW(100, 25, {mode:"par"})
    ({topar:263, trans:62, edges:382, energ:419, fpath:2, cpath:235})

    js> bigImage.timedShrinkBW(100, 25, {mode:"seq"})
    ({topar:24, trans:67, edges:133, energ:421, fpath:3, cpath:238})

(Clearly there are performance issues with the current implementation.)
Added RectArray to possible result types handled by benchmark/testing utilities.
Added documentation and added functions to interface with benchmark run.sh script.
Added stripedImage generator, and massiveImage as massive input for benchmarking.

Also, to avoid spending time generating benchmark input when I am just
loading script for investigation in the js repl, I moved the if
(benchmarking) guard to surround all the pieces that interface with
run.sh.
Fixes to benchmark to bring it more in parity with the Firefox version.

In particular, building via the RectArray abstraction I had added had
injected some very serious performance degradation in the sequential
code path, and that made ParallelArray look better than it should have
for edge-detection.

This change does the edge-detection directly via array indices, and
this brings the sequential performance back into parity with the
web-based version.  (So now I feel more comfortable starting to
attempt to fix the ParallelArray performance issues present in this
version of the code.)
Bug fix for unbound variable error.
Add variant build routine, RectArray.buildA.

RectArray.buildA has the same interface as RectArray.build, but buildA
uses an Array directly for the initial construction and filling, and
then changes the prototype of the object at the last moment so that
the result acts like a RectArray (maybe; I am not an expert at
dynamically modifying object prototypes).
Added end-to-end RESIZ[E] benchmark, with seq and par variants.

Switch to using buildA instead of build in hopes that it speeds things
up.  (Have not verified this.)

To support the RESIZ benchmark:

  - Add computeEnergy method to RectArray to parallel the one on
    ParallelArray.

  - Split the cut seam methods into seq and par variants.

The RESIZ benchmark is very very slow at the moment.  I added
print-outs of intermediate state while it runs.  There is much to be
done to bring it in parity with Firefox in terms of exercising the js
shell in the same way.

(It also may currently expose crashiness in the PJS js shell build,
but I am not sure of this since I need to pull in changes from shu and
test them to see about that.)
Fixes to shell liquid-resize.js

My changes to use a 1D array instead of a 2D array were not sound as
written, in part because later stages in the process (after
edge-detection) need to now dispatch on whether they happen to be
handed a 1D ParallelArray or a 2D one, so that they can call the
appropriate get() method.  (Also, I still need to confirm absolutely
that switching to a 1D ParallelArray was a critically required change
or not.)

Also, since we no longer universally construct a 2D array, I need to
carry around the intended width and height explicitly again (or pass
it as separate parameters, like the original benchmark did).

With these fixes in place, it looks like the parallel execution may
produce the same result as the sequential one (a better place to start
from when evaluating performance issues).
bring back more significant input for liquid-resize benchmark.
Took dead code (grayScale function) out of benchmark.