Potential fix for issue #232.

The fix is a memoization approach for the expensive recursive
resolveCtx function. Although I'm not 100% confident that the
memoization approach is correct (though intuitively it feels
correct to me), at least all the tests pass ... which I take
to mean that the memoized resolveCtx is properly generating
hygienic code in the known cases. It certainly does that for
the example given in issue #232 without incurring exponential
time.
Simplified the memoization.

After poking around the resolveCtx function's logic a bit more, I
realized that even originalName needn't be used in the memoization key
and only the context is needed. I'm now confident of the correctness
of this optimization and am willing to change the name from "Potential
fix for issue #232" to "Fix for issue #232".

It is easier to see the correctness of the assumption made by the
memoization step in a purely recursive rewrite of resolveCtx, where
every recursive step works with either a "deeper" context or a new one.
I've put that up at https://gist.github.com/srikumarks/9847260 .
OPTIMIZATION: Minor optimizations in marksof and reduceCtx.

1. ".constructor" test is known to be faster than "instanceof".
2. Reduced the number of recursive calls in marksof using a while loop.
Merge branch 'pr/284'