XSB Src (SVN)-old

backed out the standardization change to load_dunc/2, which was incorrect.
The other standardization changes stay.

remove xwams before running the tests so that the tests would be clean.

Added path_sysop standardize (to resolve symlinks & expand) and readlink (to resolve 1 syslink).
Change consult/loader to use API to manipulate consult_file_loaded and load_dyn_file_loaded. That API always standardizes filenames before doing anything. Load and add_lib_dir also standardize files.

no longer tries to remove test_ec.xwam, which led to a spurious warning.

got rid of possible memory leak in file_readlink

added the forgotten return statement in the windows branch

file standardization now first expands the file name and only then replaces symlinks with the real thing.

Added missing length to a call to strncpy.

added a new primitive to file_io:path_sysop -
path_sysop(standardize,In,Out)
Converts symlinks to regular files. For regular files is identity.
On Windows is identity -- for now.
The idea is to use this in consult and load to always eliminate symlinks.
In this way, XSB won't think that a symlink is a different file and will not be unnecessarily reloading modules.

This fixes an obscure bug in incremental tabling. The problem
arises in the following situation

1) an incremental subgoal S is updated from State_1 to State_2
2) Choice points are laid down for S in State_2
3) S is again updated

Before this change, when 3) occurred, find_the_visitors (the main
setup routine for view consistency) does not work properly. This
is because FTV traverses the choice point stack to determine when
choice points to S are present. During this process, if a CP
points to a trie instruction, that trie instruction is checked to
determine whether it points to the trie for S. However, the
routine that does this check needs to traverse the trie to the
root, and then go from the root to the subgoal frame for S -- it
is the subgoal frame that determines whether that trie
instruction pertains to S.

In prinicple this should work fine, but there is a catch. During
the update in 1) S gets a different subgoal frame. I dont think
this is necessary (I inherited this decision) but in any case
this means that State_1 has SF_1 and State_2 SF_2. Thus the CPs
laid down in 2) pertain to SF_2, but the pointer to the root of
the answer trie for S was not being updated. Thus, FTV could
only find CPs that pertain to SF_2, which did not trigger the
creation of a new view consistency choice point.

Once this became apparent, the fix was easy: I just had to reset
the pointer from the root of the answer trie and things now seem
to work fine.

So in a nutshell, FTV was working fine as long as there weren't
repeated updates to the same goal. I should have checked this
case earlier, so shame on me.

Chasing down the bug caused me to scrutinize parts of the
incremental update code. The use of attributed variables within
the view consistency mechanism was incorrect and still needs to
be fixed. There doesn't seem anything obviously wrong with the
rest of the code I looked at, although I did add some checks for
possible errors.