Proper fix for delayed deactivation.

The original pull request is here: https://github.com/enigma-dev/enigma-dev/pull/771

Essentially, according to GM:S, we have the following behavior:
>NOTE: If you deactivate an instance on room start (ie:from the room creation code, or from an instance create event of an instance within the room) all instances that are placed within the room from the room editor will still run their create event before being deactivated.

Contrary to what I said in my original bug report, instance creation code IS actually fired correctly in ENIGMA. However, the "room instance creation" code (that code you add in the room editor on a per-instance basis" is *not* fired if the object is deactivated, because it is implemented like so:
```
with(100001) { //Using the instance ID directly.
   some_code();
}
```
The reason this doesn't work is that the instance is not listed on the active instance list, so an empty iterator is returned. 

My fix simply adds another macro, "with_room_inst", which functions just like "with", but uses a lookup function that checks the deactivated instance list as well as the activated one. This macro is ONLY used in "room instance creation" code. 

Additionally, I have to track which instances are currently deactivated, in case an instance calls "instance_destroy()" in its "room instance creation" code. Otherwise, it will try to deactivate itself twice. The only way I could think to do this (sanely) was to add a parameter to object_basic that is updated on calls to activate() and deactivate(). I called this parameter "is_active_QBwfSd" in an attempt to minimize the risk that the user accidentally sets/reads it.

I am fairly sure this is a stable fix (I tested it extensively), but there's always a risk when messing around with instance creation. Fortunately, it *should* only be a risk to objects that do fancy stuff in the room instance creation code, which is not a lot (otherwise this bug wouldn't even exist in the first place).