some expressions with side-effects get rewritten wrong

This fixes additional bugs that turned up in issue 1452
http://code.google.com/p/google-caja/issues/detail?id=1452

Some rewriter rules call reuse(expr), which generates code to
capture the expr in a temp var, so that expr's value can be used
more than once without executing expr more than once.

For example, code like this:
  o.p = v;
gets transformed into approximately:
  x0___ = o,
  x1___ = v,
  x0___.canWrite_p___
    ? x0___.p = x1___
    : x0___.w___('p', x1);

As an optimization, reuse() avoids creating a temp var when it
notices expr is a literal or a simple reference.  So in reality
the case above would be transformed into approximately:
  o.canWrite_p___
    ? o.p = v
    : o.w___('p', v);

Unfortunately, allowing direct variable refs means that most of
our uses of reuse() are wrong.  Most rules that use reuse() call
reuse() twice, and a side effect in the second expression can
happen before the reference to the first expression.

For example, code like this:
  o.p = (o = null);
gets transformed into approximately:
  x1___ = (o = null),
  o.canWrite_p___
    ? o.p = x1___
    : o.tryWrite('p', x1___);
which clobbers o too early.

This change fixes that.  Instead of calling reuse() multiple
times, I'm creating an object Reusable that understands how to
rewrite multiple expressions simultaneously.

[felix8a, 2012-03-19 21:00:39]

ping

[metaweta, 2012-03-19 21:18:09]

lgtm

http://codereview.appspot.com/5849049/diff/1/tests/com/google/caja/parser/qua...
File tests/com/google/caja/parser/quasiliteral/ES53RewriterTest.java (right):

http://codereview.appspot.com/5849049/diff/1/tests/com/google/caja/parser/qua...
tests/com/google/caja/parser/quasiliteral/ES53RewriterTest.java:208: "  return
f(f = 208, i, i++);\n" +
I think you meant 209 ;)

[felix8a, 2012-03-19 22:57:15]

@r4813