Avoid race condition due to yield, abandon waiting on CmdExtension

This should get rid of the race condition described in #140.

The swapping of `parseobj` in `ScheduleSheetCommands` will interfer with the yielding of CPU time if `sci.maxtimeslice` is exceeded.  This can cause commands to get executed twice.  To avoid this, I'm now passing the `parseobj` around in all function invocations, and the saveundo as well.  That way I won't have to rely on some state which might be subject to change.
    
Since the `ResumeFromCmdExtension` only has a single argument, it doesn't fit in with the new signatures.  As there are no calls to that function in the whole code base, the function has been removed, along with the related `cmdextensionbusy`.  If this machinery is required in some third-party setup, then its use should be documented and preferably changed.  It might be best if any command extension accepts a single callback as an argument and calls that if it wants to resume operations, without having to worry about what parameters to pass.  That way, the code invocing the extension could take care of wrapping all required arguments in a suitable closure.

I'm not yet sure whether this eliminates race conditions due to the `maxtimeslice` handler. It might well be that delayed commands might get mixed up with newly arriving commands, causing them to get executed in an unpredictable order. Haven't checked whether there are any provisions to avoid such scenarios.

I've also edited the `Makefile`, since I don't have a `closure-compiler` binary here. I'm invoking the JAR file manually. I haven't recompiled the `static/ethercalc.js` since I prefer to only edit source code. Don't forget to recompile before the next release, but perhaps we can include some more source modifications in that next compile.