Resolve include directives relative to each file

[ngwood]

This commit changes how ADMS resolves include directives. ADMS currently does this relative to the current working directory, each user-provided search path and the ADMS include directory, in that order. This is not typical of Verilog-A compilers or compilers in general.

Following are just a few examples of why the current ADMS behaviour is undesirable.

Example 1:

A.va            `include "sub/B.va"
sub/B.va        `include "C.va"
sub/C.va        // desired file
C.va            // stray file

"C.va" will always find the stray file in the current working
directory.

Example 2:

dir/A.va        `include "sub/B.va"
dir/sub/B.va    `include "C.va"
dir/sub/C.va    // desired file
dir/C.va        // stray file

"sub/B.va" will only find the desired file if "dir" is manually
added to the search path. "C.va" would then always find the stray
file, unless "dir/sub" had been previously added to the search
path. Either of these actions could have unintended consequences.

This commit addresses these limitations.

ADMS will now first look for files relative to the directory of the file containing the include directives and will behave the same way regardless of the current working directory or how many nested include directives are used, without the need to specify additional user-defined search paths.

[ngwood]

I'm not 100% sure on whether this will work on Windows yet. Also, the dirname function had already been defined statically in admsXml.c meaning it's not defined in library admsElement like almost all other functions of this kind are. admsXml.c is used to create admsXml; but if you ever wanted to link against the admsPreprocessor library elsewhere you'd run into problems. Is it worth relocating the dirname and dependent functions? They could be made part of mkelements.pl. I'm thinking it would be safer and more consistent. Could we rename dirname to adms_dirname at the same time perhaps, as dirname is a standard library (string.h) function name?

[ngwood]

Is it possible to check this builds correctly on Windows?

[ngwood]

Commit 71c6d35 contains all changes to in the pull request to preprocessorLex.l. The common static functions in preprocessorLex.l and admsXml.c can be cleaned up together at a later stage.