calling convention for types that overlap (e.g. Object, Number, String, Boolean)

[jmesserly]

for types where we used JS values directly, we need to ensure calls don't go through JS method dispatch. This is already handled for binary operator call sites (see _isJSBuiltinType) based on an earlier CL, however a bunch of issues remain:

• Object is not sealed. Those methods need to be overridden too. I think we support == already but not others. Easiest fix might be just to have DartObject that all Dart objects extend.
• Number/String/Boolean -- we need to declare these methods correctly, and make sure everything is going through the right calling convention (not just binary ops).

[jmesserly]

also, we have issue with name collisions, e.g. core.String vs the String builtin

[rakudrama]

FYI dart2js has a 'DartObject' (called Object) to avoid polluting the JavaScript Object.
That also allows toString to be different.

It would be nice to take advantage that some js.String methods are identical to core.String methods (e.g. toLowerCase()) but most are not. substring() has stronger index checking but is otherwise the same, and some produce different results (e.g. trim() which currently has an implementation that calls js.String.trim() and checks the result - usually there are none of the weird extra whitespace characters)

[jmesserly]

fyi @vsmenon @jacob314

[jmesserly]

fixing this along with #138