Revert revisions of mine: 51930, 51947

These were the variable substitution delaying in the [object] code. It is
no longer needed due to the workaround [object]delayed_...=yes|no.
Removes repeated wml parsing. Reverts behavior to mostly what was in 1.8
If ABILITY_TELEPORT is added by an [object], or [object][effect][filter]
contains $this_unit, delayed_...=yes is required for the modifications
to work as expected.
However, if the same object wants to get variables substituted and
add ABILITY_TELEPORT to a unit, the code would have worked in 1.8
but doesn't in 1.9.
(bug #18893, bug #19225)

(Browse SVN revision 52448)

Works for me (on 1.9.10+SVN 51958M).

No testcase needed. These error messages are invalid. The fix would be to delay variable substitution much more which requires refactoring a lot of called subfunctions. I don't feel like doing it pre-1.10 since this could cause a lot of bugs, so if this is the only problem you'll have to live with these false positives.

It works now. However, the engine spits out the following error on a unit being given an object ("move to" event):

"warning engine: variable_info: retrieving member of non-existent WML container, teleport_unit.side"

Yes, the previous ABILITY_TELEPORT implementation didn't have any variables to substitute, so the cfg.get_parsed_config() call in game_events.cpp:1863 substitutes variables too early at a time when the wml variable teleport_unit isn't yet set.
We should probably eliminate such call pathes in the engine, that is, passing vconfigs to make variable substitution as late as possible.
(I worked around a similar problem with the [unit] callstack recently.)

This may be an issue with premature variable substitution. Try replacing the {ABILITY_TELEPORT} macro with its expansion, but wherever the macro has $teleport_unit use $|teleport_unit instead.