The last usage of it was in `Player`, which anyway should operate
only on newly created objects that don't have any virtual properties
nor watchers. So it is safe to replace with `define_value`, that
also cannot fail.
`__proto__` seems to behave much like a regular data property. So
simply remove the `prototype` field of `ScriptObject` in favor of
storing the prototype in the general properties hash map.
It was regressed in #4822 when changed to use `flat_map`. But
currently Rust emits suboptimal code for such case. For now use
`Vec::with_capacity` manually to avoid unnecessary re-allocations.
The former native initializer call was incorrect and would cause spurious coercion failures. Since existing code assumes the error fork of `coerce_to_object` means undefined or null, this was causing coercions and parameter typechecks against primitives to fail in the most general case.
Attempting to fix this by providing the primitive value as native initializer argument instead causes a stack overflow. This is because native initializer arguments still have to be typechecked, and in the most general case this means... coercing the primitive value we're already coercing into an object... into another object. This won't work.
Since primitive initializers aren't going to do anything that native coercions need to care about, I'm just removing the initializer call.
Instead, the following terms are used:
* Static classes, to refer to `Class<'gc>`. Shortened to "class" in contexts where this is not ambiguous.
* Class objects, to refer to objects that represent a particular class. Also shortened to "class" in non-ambiguous contexts.
Downstream of this, the `base_constr` (referring to the class that a currently called trait has been pulled from) is now called `subclass_object` and several `TObject` methods have also been renamed.
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.