Fixing bug with static function resolution

[ghost]

Ensures the initial class scope is at the top of the stack so that it is popped first; allows overriding of apply and call etc where these are present in the scope stack due to Class deriving from Function

I had noticed that I kept on getting errors when transpiling code that used ExternalInterface.call, where the JavaScript ended up just as:

ExternalInterface.call("MyMethod");

rather than the calls to ExternalInterface.available or addCallback, which were correctly emitted as:

mx.external.ExternalInterface.addCallback("fncName", myCalback);

Having looked into this, there's a scope resolution where the compiler is looking for a definition of "call" within the current scope - at the top of which is the ExternalInterface class, and it should then expand the search to the base classes. As a static type, the base of ExternalInterface is Class, the base of Class is Function, and the base of Function is Object. However, in the StaticTypeIterator initilalizer, the code was adding the initial scope (ExternalInterface) to the stack and then adding the built-in Class definition; this is the wrong order, since the iterator's next method pops the most recent addition first.

So to correct this, we push the Class type and then the initialType (ExternalInterface in my case) is added on top. Note the "skipThis" flag which affected the behaviour; checking for this here simplifies it a little bit, as the flag (if used?) indicates that the initialType should be ignored and would have been added to the visited list rather than onto our stack. The old implementation of this - just calling next() if skipThis was true - would have exposed the bug, as the call to next() would have removed the Class definition...