Massive changes to replace the site API with a new Invoker based one.

[arthurp]

The initial change introduces a bugs and missing features in a couple of places. These will be fixed before merge into master.

• [x] OrcXML does not handle what used to be JavaClassProxy correctly.
• [x] Complete conversion to strict def/routines.
• [x] Change interpreter to avoid having closures as Readables. This will make it so the only readable is Future.
• [x] Closures are not correctly handled in Token.newObject.

[arthurp]

I have posted this before I have corrected the broken things so that review can start ahead of completing the last few things. If you would prefer to wait, go ahead.

[jthywiss]

Since you're in here, can the ResolvableCollection stuff be collapsed back into ClosureGroup?

[arthurp]

It could be yes. However, I don't think we should. It's a extra abstraction that might be useful later and it doesn't confuse the code.

[arthurp]

All bugs mentioned above are fixed.

The only issue at this point is that these changes introduce a probably bug in TokenReplacement:251. I suspect this problem will go away once distrib has been updated to use the assumption that all Readables are futures and closures are never lenient.

[arthurp]

About using Invokers in dOrc. I'd be interested to know how you think you could use them specifically. For instance if you want to be able to serialize them in some cases we should probably add "Take the serializable contract serious, dude" to the documentation so that I don't forget that's important.

Some invokers will probably be totally non-serializable (for instance, if they are invokers for JavaScript or native code functions running in Truffle, since those would include references to local truffle, graal, or even native execution state). But we can control that so it seems manageable.

[arthurp]

There last two commits should address all the comments you have brought up.