remove fixed paths from code

As per this thread on the user mailing list, I've found that one can't actually use
the --libdir, --includedir, etc. options to the autoconf configure program:

http://marc.theaimsgroup.com/?l=axis-c-user&m=115956538314942&w=2

Here's the crux of the problem: hard-coded paths. While I appreciate that these are
easier to write than a fully-configurable package, the documentation in the INSTALL file
and the use of autoconf implies that one can customize the installation. For
example, the INSTALL file says:

Please run './configure --help' in samples folder for more information on
configure options.

As it happens, when I discovered that the package was going to install
about 15 libraries and 375 header files, I purposefully used the
standard autoconf configure options to put these in subdirectories:

./configure --prefix=$(INSTALL_PATH) --enable-tests \
--bindir=$(INSTALL_PATH)/bin/axis2 \
--includedir=$(INSTALL_PATH)/include/axis2 \
--libdir=$(INSTALL_PATH)/lib/axis2 \

With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all
compiles OK and installs OK. It's also a fairly standard Apache way of doing
things – the APR and httpd projects use the apr-<majorversion> and apache2
subdirectories, for example, to keep their headers and libraries from polluting
the user's --includedir location.

Alas, in axis2_conf_builder_process_transport_senders(), we have this code:

repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder->
desc_builder->engine, env);
temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env);
temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env);
temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env);
path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env);

This means that, in effect, the --libdir option to configure is useless, because the
code is going to ignore whatever the specified installation locations were and go
looking in the $AXIS2C_HOME/lib location regardless.

What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my
$INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's
a workaround caused by what I'd suggest is a pair of bugs.

First, I'd suggest that there should be no hard-coded paths like the ones I see
in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c.
These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH();
there may well be other similar functions I'm not aware of, though. Such paths
should be determined from configuration parameters. For example, programs
could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile
time using an option to ./configure, and finally in the current directory. The axis2.xml
file would then, in turn, include the paths to the directories used for logs, libraries, services,
modules, etc. It would also be nice if at compile time and run time one could specify
a different name for the axis2.xml file – for example, Apache httpd accepts an -f
run-time option to use a non-standard configuration file.

Second, whole autoconf system for axis2c needs some work. I'll put details into a
second enhancement request, but as far as this particular bug is concerned, I'd suggest
that since --libdir does correctly install the libraries into a given location, it's wrong to then
go looking in $AXIS2C_HOME/lib despite what the user requested.