Simulated efunctions (simul_efuns)

There is a mechanism to allow the mudlib to simulate efunctions.  All
simulated efuns must be defined in a special file (the name and location
of which are to be specified in config.example).

When compiling an object and a function call (not a call_other) is found that
has not been defined in the object and is not an efun, then the driver
will search for that function in the list of simulated efuns.  If the
function is found in that list, then the driver sets up a call_other to
that function (as defined in the simulated efun file).  Note, the result
of the call_other does not have to be typecasted, since the type will be
automatically set by the compiler.

Simulated efuns have many uses.  One is that it is now possible to make major
changes (and even removals) to the behavior of efuns without modifying
the driver (by making a simul_efun having the same name as an efun).  Suppose
you wish to modify the behavior of the move_object() efun.  You could do
so by defining a simulated efun having the same name.  The simulate efun
could perform various restrictive checks and then call efun::move_object().
The efun:: prefix is necessary so that the driver will know you wish to call
the move_object efun and not recursively call the simulate_efun within which
the call to move_object is contained.  [Note that valid_override() in master.c
can be used to conrol which simul_efuns may be overridden via the efun::
prefix].  Simulated efuns are also useful for adding functions that many
different objects may need to call but which aren't appropriate for
inclusion in an inherited file.

Any function in the simulated efun file that is declared static, will
not be callable by functions outside the simulated efun file.