Attempt to fix delayed deactivation by delaying the command itself.

This command fixes a nasty bug I ran into regarding instance_deactivate_*() and room events. From the GM docs:

```
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.
```

The following game demonstrates this:
https://drive.google.com/file/d/0B1P7NepPcOslSjhaZFMzdE80ems

If run in GM:S, the following messages are shown. In Enigma, only the first message is shown.
```
show_message: CREATE OK
show_message: ROOM INST OK
```

The first message is an object's "create()" message, and the second is a room's instance_create method for a given instance. Note that one of the objects in the room calls "instance_destroy_all()" in its create() code --this is the source of the problem!

To solve this, I created a command structure that allows instance_deactivate*() and instance_activate*() commands to be delayed until after room loading is complete. This was the simplest, most robust way I could find for fixing this bug; other options include leaving the object in the active list but setting a "toBeDisabled" flag (it needs to be in the active list because with(object){} must still work), but this seems more likely to lead to esoteric bugs. Finally, it should be obvious that delaying deactivation events necessitates delaying activation events.

I've tested that this pull request fixes the observed bug, on both the Precise and BBox collision systems, bringing behavior in line to what was observed in GM5 and GM:S.