This also makes it more difficult to accidentally build a class without calling it's initializer. Native/builtin class initializers should also be running now, too.
The only minor bit of jank is that we need a class initialized bit to flag classes we've already run, because our current lazy-init design for traits causes classes to be constructed twice. This is temporary and I intend to remove it along with lazy-init traits.
This effectively turns calling `ArrayObject`'s associated methods into an alternate constructor path. We even make sure to run instance initializers. You also no longer have to grab the `array` system constructor, so we get to remove that code.
Native initializers are a separate, parallel initialization chain intended for all object construction that is not directly triggered by `Op::Construct` and friends. This allows us to implement classes that cannot be directly constructed by user code, but can be constructed by native code or supercalled into from non-native.
This also incurred a large number of ancillary changes, as it turns out nearly every native object is currently pulling a prototype and sticking it into an object. Right now, I have it instead pulling the constructor out of the prototype, but a future PR will also remove `system_prototypes` as well.
Other ancillary changes include:
* `Domain` now supports partial initialization to avoid an order-of-events issue. Accessing domain memory on a partially-initialized `Domain` will panic.
* `Domain` construction requires a full `activation` now, except for `global_scope` which needs to be initialized later with valid domain memory before user code runs.
* Pretty much every native object constructor now takes a proto/constr pair
* Trait lookup was rewritten to handle this. It's still buggy - seven tests don't work
* `TObject.construct` now actually does the full object construction dance. This allows `ClassObject` to implement the ES4 object construction pathway directly while `FunctionObject` maintains ES3 compatibility.
This is a tentative commit; there are still seven failing tests that I need to fix.
For various reasons, we store the dispatch list for an object on a separate property of an `EventDispatcher` rather than dictating that all children of `EventDispatcher` use a specific object type. This is because `EventDispatcher` is a very general class with lots of object representations it needs to cover. So instead, we introduce a new object representation for a *property* and store it in a Ruffle private namespace that is as isolated from user code as alternate object representations are.
This entirely abolishes the "global scope object" in AVM2. I even had to redefine several global object functions to work with the bottom of the scope stack, which seems to be where ASC likes to stick the script scope.
This appears to work almost like it's own TObject method; you can run `Object.prototype.toLocaleString` on all sorts of things and it has separate behavior to what the class method for it might be. I have attempted to match Flash Player as best as I can.
This code also ensures that the prototypes of each system object are created in the appropriate `TObject` impl. This ensures that, for example, `new Array` hands you back an actual array.
David Wendt