- they are not used in the example
- they are injected as command classes by setuptools_dso.setup itself

Only need to include @loader_path/. if a dependency
is in the same directory.

@loader_path prefix requires dependent libraries to be in the same
directory or to use install_name_tool to change the name after linking.
With this fix, linker's -rpath can be used instead.

Which requires freeze_support()

Try to avoid problems only detectable in tag builds.

Expedite recommendation by Cython authors to distribute
generated c/c++ source files.

package_dir needs to be taken into account for inplace builds, because
then inplace directory of a package != directory of the package when it
is installed. For example setuptools_dso itself uses
`package_dir={'':'src'}` in its setup.py and this way for inplace build the
directory of setuptools_dso package is not setuptools_dso/ but
src/setuptools_dso/ instead.

However `build_dso --inplace` was installing built libraries without
taking package_dir into account. For example with amended example/ test,
libdemo.so was installed into dsodemo/lib/libdemo.so instead of
src/dsodemo/lib/libdemo.so, while dtest.so was correctly installed into
src/dsodemo/ext/dtest.so . As the result it was not working:

    + python -m dsodemo.cli
    Traceback (most recent call last):
      File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
        "__main__", fname, loader, pkg_name)
      File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
        exec code in run_globals
      File "/home/kirr/src/tools/py/pypa/setuptools_dso/example/src/dsodemo/cli.py", line 15, in <module>
        from .ext import dtest
    ImportError: libdemo.so.1.0: cannot open shared object file: No such file or directory
    .../setuptools_dso$ ll example/
    итого 16
    drwxr-xr-x 4 kirr kirr 4096 дек  4 18:12 build
    drwxr-xr-x 3 kirr kirr 4096 дек  4 18:12 dsodemo
    -rwxr-xr-x 1 kirr kirr  639 дек  4 18:12 setup.py
    drwxr-xr-x 3 kirr kirr 4096 дек  4 18:06 src
    .../setuptools_dso$ ll example/dsodemo/lib/
    итого 136
    -rwxr-xr-x 1 kirr kirr 68888 дек  4 18:12 libdemo.so
    -rwxr-xr-x 1 kirr kirr 68888 дек  4 18:12 libdemo.so.1.0
    .../setuptools_dso$ ll example/src/dsodemo/ext/
    итого 124
    -rwxr-xr-x 1 kirr kirr 119000 дек  4 18:12 dtest.so
    -rw-r--r-- 1 kirr kirr      0 июл 30 21:37 __init__.py
    -rw-r--r-- 1 kirr kirr    110 дек  4 18:12 __init__.pyc
    .../setuptools_dso$ ldd example/src/dsodemo/ext/dtest.so
            linux-vdso.so.1 (0x00007fffae3fd000)
            libdemo.so.1.0 => not found
            libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1c3bf20000)
            libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1c3bd9d000)
            libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1c3bd83000)
            libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1c3bd62000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c3bba1000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f1c3c149000)
    .../setuptools_dso$ objdump -x example/src/dsodemo/ext/dtest.so |grep PATH
      RUNPATH              \$ORIGIN/../lib:$ORIGIN/../lib

-> Fix it by taking package_dir option into account in --inplace dsocmd handler.

Note1: The code to do so mimics build_ext from setuptools:

    https://github.com/pypa/setuptools/blob/v42.0.2-0-g1d03fdc9/setuptools/command/build_ext.py#L89-L107

Note2: Sources of Extension and DSO are specified with full path from project
top-level, because it already works this way for unmodified Extension even in
presence of package_dir.

Don't allow one to pass into setuptools_dso.setup() e.g. build_ext that
does not inherit from setuptools_dso.build_ext.

Fixes: 67d717a6 (wrapper setup don't clobber)

The code was trying to create solibbase symlink pointing to -> outbaselib, e.g.

    libdemo.so.1.0 -> build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0

However if the source file in worktree already exists, symlinking was
failing with an error. Fix it by making sure that source file does not
exist before calling os.symlink.

Also there was related thinko in log.ingf describing who points to
who/where, which is corrected along the way.

Without the fix newly added test fails as

    ...
    running build_dso
    Building DSOs
    building 'dsodemo.lib.demo' DSO as build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0
    creating build
    creating build/temp.linux-x86_64-2.7
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DBUILD_FOO -c foo.c -o build/temp.linux-x86_64-2.7/foo.o -DALL -DISC
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DBUILD_FOO -c bar.cpp -o build/temp.linux-x86_64-2.7/bar.o -DALL -DISCXX
    cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/dsodemo
    creating build/lib.linux-x86_64-2.7/dsodemo/lib
    x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/foo.o build/temp.linux-x86_64-2.7/bar.o -o build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0 -Wl,-h,libdemo.so.1.0
    symlink libdemo.so.1.0 -> build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0
    creating dsodemo/lib
    copying build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0 -> dsodemo/lib
    copying build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so -> dsodemo/lib
    running build_dso
    Building DSOs
    building 'dsodemo.lib.demo' DSO as build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DBUILD_FOO -c foo.c -o build/temp.linux-x86_64-2.7/foo.o -DALL -DISC
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DBUILD_FOO -c bar.cpp -o build/temp.linux-x86_64-2.7/bar.o -DALL -DISCXX
    cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
    x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/foo.o build/temp.linux-x86_64-2.7/bar.o -o build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0 -Wl,-h,libdemo.so.1.0
    symlink libdemo.so.1.0 -> build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0
    error: [Errno 17] File exists

It is used in several places and will be used more in the next patch.

build_dso for inplace mode copies DSO built in build/ into worktree.
However if the destination directory does not exist yet, copy_file
fails. Fix it by making sure before copying that destination directory
exits.

Without the fix added test fails as follows:

    ...
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/dsodemo
    creating build/lib.linux-x86_64-2.7/dsodemo/lib
    x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-IbFBHb/python2.7-2.7.16=. -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/foo.o build/temp.linux-x86_64-2.7/bar.o -o build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0 -Wl,-h,libdemo.so.1.0
    symlink libdemo.so.1.0 -> build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0
    copying build/lib.linux-x86_64-2.7/dsodemo/lib/libdemo.so.1.0 -> dsodemo/lib
    error: [Errno 2] No such file or directory: 'dsodemo/lib/libdemo.so.1.0'

This covers .so files created with soversion, e.g. there can be
libdemo.so and libdemo.so.1.0 . The latter is covered by added patern.

No need to change dylib and dll patterns - according to current
setuptools_dso code, the soversion is either used before '.dylib'
suffix, or, for '.dll' case is not present in file name at all.

seems that some versions of GCC expand shell
variables in -Wl, which loses $ORIGIN