Fix the IVirtualMachine::CreateObject overload order

[ejams1]

IVirtualMachine declares its two CreateObject overloads in slot order (properties overload, slot 0x16, then the two-argument one, slot 0x17). MSVC lays out overloaded virtuals in reverse declaration order, which is why every other overload pair in this header (GetScriptObjectType, GetScriptObjectTypeNoLoad, CreateArray, SetCallableFromTasklets, GetVariableValue, DispatchMethodCall) is declared in reverse slot order. Because this pair is not, vm->CreateObject(name, obj) compiles to vtable +0xB0, and on 1.11.240 that slot is the properties overload.

What the 1.11.240 vtable (BSScript::Internal::VirtualMachine, ID 614600) holds:

• slot 0x16 (+0xB0), 0x2119990: CreateObject(name, properties, obj). It computes a property count from the map and calls CreateObjectWithProperties ([rax+48h]).
• slot 0x17 (+0xB8), 0x2119930: CreateObject(name, obj), which is mov r9, r8; xor r8d, r8d; call [rax+48h].

How it shows up. PackVariable for a form calls CreateObject(typeInfo->name, object) (BSScriptUtil.h:549) when the form has no bound script object yet. The call lands in the properties overload, which treats the BSTSmartPointer<Object>& as a property map and passes a garbage out-pointer down. The game then crashes reading it at Fallout4.exe+0x211edd0. We hit this in a plugin dispatching DispatchStaticCall<Actor*, AlchemyItem*>; a full dump shows the call at +0xB0 and the bad r9. After this change the three call sites in that plugin compile to +0xB8.

The fix swaps the two declarations. The slot comments stay with their functions.