Fix Boost detection for newer Debian derivatives

The Boost library is now multiarched, so the Boost libraries may live
in e.g. /usr/lib/x86_64-linux-gnu.  The GNU autoconf-archive
`ax_boost_base.m4` tests don't account for this as of 13 Sep 2014,
[git rev. 3d67989][1].

This commit looks for `dpkg-architecture`, and uses the
`DEB_HOST_MULTIARCH` variable to generate another subdirectory
candidate for search.

[1]: http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_boost_base.m4;h=d7c9d0d3986e4dd4556dad84809d0f0fabdbac6b;hb=HEAD
Fix Boost link problems on newer Boost versions

On newer versions of Boost, reportedly from v. 1.50 on, the
`libboost_thread.so` shlib needs symbols from `libboost_system.so`:

    $ ldd /usr/lib/x86_64-linux-gnu/libboost_thread.so | grep boost
	libboost_system.so.1.54.0 =>
	  /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f801bbe1000)

This breaks the `emcweb` linking:

    $ make
    [...]
    Linking emcweb
    g++ [...] -o ../bin/emcweb [...] \
        -lboost_serialization -lboost_thread -lpthread -ldl
    /usr/bin/ld: objects/emc/usr_intf/emccontroller.o:
        undefined reference to symbol '_ZN5boost6system15system_categoryEv'
    //usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0:
        error adding symbols: DSO missing from command line

This commit adds autoconf detection of `libboost_system.so` and fixes
the linker command accordingly.

Additionally, it looks like at least newer Ubuntus and Fedoras have
dropped the Boost `--layout=tagged` build option, so shlibs with the
`-mt` component in their filename no longer exist.  On the older
Wheezy, these are just symlinks to the shlib without `-mt`, anyway, so
these can just be dropped.

The autoconf detection enables compiling for older Boost versions
where this may be necessary:

      ./configure --with-boost-thread=boost_thread-mt
Merge pull request #319 from zultron/boost-linking

Boost linking