Automatic Garbage Collector (GC)
I have added it to mud++ to assure that objects which have references on
VM stack do not get deleted as long as there is even one pointer to them.
This allows implementation of VM sleep() and VM static/object memory.

Main code of mud++ is in control of creating and destructing objects.
Only thing you have to keep in mind when coding c++ part is to use
obj->fordelete() instead of delete obj for all objects inheriting from
VMObject. Once object is marked by fordelete() call it is illegal to
reference it from main c++ part (just as it would be deleted).
From this moment on, only GC and some VM handling routines are allowed to
manipulate them.


What happens to obj when fordelete() is called ?
Normally, just don't care about that , but if you want to know, here it is.
Pointer to object is put onto GC stack. Object isn't deleted until GC run.
When GC starts working, it checks all VMObjects referenced by pointers on
stack if their ref_count ==0. If it is they are deleted, if no it means that
some VM routine needs them - they stays for the moment. It is possible that
GC run will not collect all possible objects - if destructor of object
call fordelete() for it members, thay may, but must not, be deleted.
They will be collected next time.


Small possibility of memory leak.
There is a chance that objects would lock up and do not get deleted.
It will not happen in near future as VM is to infant, but it can pop in
later. Imagine that we have two objects obj1 and obj2 and both of them
have private VM variables. They reference each another, but are not referenced
anywhere else. They should be deleted, but they won't as each one's ref_count
is 1. Of course similar thing can happen with larger number of objects.
There is workaround for it - in such objects we can add functions which would
dereference all variables. Such function should be call at fordelete().
We can also do it happen automatically , by either blindly dereferencing 
all objects, or following pointers and marking objects 
(which is more accurate, but a LOT harder to write).
We should begin to worry when we will reach VM obj-local memory.