Yet another control path where parallel ion script may be invalidated.

Hopefully we will come up with a more maintainable way to deal with
the pending invalidations; but for now, just put another guard in.
Bug 840512: generalize toolchain.m4 to match newer Apple clang version string.
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.)