This is limited by the fact that we currently cannot store type metadata in static tables. I don't think it's necessary to do so as of yet as pretty much every actual parameter type I *could* shove in here turned out to be optional and broke tests if it wasn't. Still, it's probably useful enough for new classes to include.
This is very wrong: Strictly speaking, we should not be instantiating anything that needs a scope when we install the trait. We just create a slot for it to go into. Script initializers are responsible for providing a scope stack to instantiate traits into.
This pushes a few more ancillary changes:
* `has_proto_in_chain` no longer checks interfaces (since it exists to serve `instanceof`, which does not respect them)
* Interfaces no longer live on prototypes. They now live on class constructors.
Because we have stuff running in early globals, we stlil need a more elaborate version of this function that *does* take `fn_proto`. We also can't pull `scope` from the activation since this gets called to install traits.
This also includes protections on `String` to prevent it from overwriting itself. All user-constructed primitive objects start out boxing `Value::Undefined` and future constructor implementations should check what's already been boxed before overwriting it with user arguments.
For various reasons, this is kind of incomplete:
1. We need to support native event subclasses, so we can't just pull one class from `activation` (yet).
2. We can't run native instance initializers without overwriting the native object.
I expect these to be fixed in a future PR where I start adding native event types.
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.
David Wendt