Fixed SF bug #1297 (Python imports)

This changeset resolves several issues related to python imports.
For example, it's possible now to import modules having same module
names, but belonging to different packages.

From the user's viewpoint, this patch gives a little bit more control on
import directives generated by swig. The user may choose to use relative
or absolute imports (docs are provided in separate PR).

Some details:
  - we (still) generate import directives in form 'import a.b.c' which
    corresponds to absolute imports in python3 and (the only available)
    ambiguous one in python2.
  - added -relativeimport option to use explicit relative import syntax
    (python3),

Tests are under Examples/python, these are in fact regression tests but
with the current swig testing framework it seems to be impossible to put
appropriate tests under test-suite.

Closes #7

Examples/python/import_packages/same_modnames1/pkg2/Makefile

@@ -0,0 +1,15 @@
+TOP        = ../../../..
+SWIG       = $(realpath $(TOP)/../preinst-swig)
+SWIGOPT    =
+LIBS       =
+
+build:
+	$(MAKE) -f $(TOP)/Makefile SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
+	LIBS='$(LIBS)' TARGET='foo' INTERFACE='foo.i' python_cpp
+
+static:
+	$(MAKE) -f $(TOP)/Makefile SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
+	LIBS='$(LIBS)' TARGET='foo' INTERFACE='foo.i' python_cpp_static
+
+clean:
+	$(MAKE) -f $(TOP)/Makefile TARGET='foo' python_clean

Examples/python/import_packages/same_modnames1/pkg2/foo.hpp

@@ -0,0 +1,5 @@
+#ifndef PKG2_FOO_HPP
+#define PKG2_FOO_HPP
+#include "../pkg1/foo.hpp"
+struct Pkg2_Foo : public Pkg1_Foo{};
+#endif /* PKG2_FOO_HPP */

Examples/python/import_packages/same_modnames1/pkg2/foo.i

@@ -0,0 +1,6 @@
+%module(package="pkg2") foo
+%{
+#include "../pkg2/foo.hpp"
+%}
+%import  "../pkg1/foo.i"
+%include "../pkg2/foo.hpp"