appropriate filename translation on the host system. Apart from this point,
users should also note that there's a slight change in the API functions
too. The DSO now contains its own to-be-converted filename
("dso->filename"), and at the time the DSO loads the "dso->loaded_filename"
value is set to the translated form. As such, this also provides an impicit
way of determining if the DSO is currently loaded or not. Except, perhaps,
VMS .... :-)

The various DSO_METHODs have been updated for this mechanism except VMS
which is deliberately broken for now, Richard is going to look at how to
fit it in (the source comments in there explain "the issue").

Basically, the new callback scheme allows the filename conversion to
(a) be turned off altogether through the use of the
    DSO_FLAG_NO_NAME_TRANSLATION flag,
(b) be handled in the default way using the default DSO_METHOD's converter
(c) overriden per-DSO by setting the override callback
(d) a mix of (b) and (c) - eg. implement an override callback that;
    (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..."
        and if so, convert "blah" into "blah32.dll" (the default is
	otherwise to make it "blah.dll").
    (ii) default to the normal behaviour - eg. we're not on win32, so
         finish with (return dso->meth->dso_name_converter(dso,NULL)).
(e) be retried a number of times by writing a new DSO_METHOD where the
    "dso_load()" handler will call the converter repeatedly. Then the
    custom converter could use state information in the DSO to suggest
    different conversions or paths each time it is invoked.