Fix 338252 - building valgrind with -flto (link time optimisation) fails

Fix 338252 - building valgrind with -flto (link time optimisation) fails

* Addition of a new configure option --enable-lto=yes or --enable-lto=no
  Default value is --enable-lto=no, as the build is significantly slower,
  so is not appropriate for valgrind development : this should be used
  only on buildbots and/or by packagers.

* Some files containins asm functions have to be compiled without lto:
    coregrind/m_libcsetjmp.c
    coregrind/m_main.c
  If these are compiled with lto, that gives undefined symbols at link time.
  The files to compile without lto are
    coregrind/m_libcsetjmp.c
    coregrind/m_main.c

  To compile these files with other options, a noinst target lib is defined.
  The objects of this library are then added to the libcoregrind.

* memcheck/mc_main.c : move the handwritten asm helpers to mc_main_asm.c.
  This avoids undefined symbols on some toolchains. Due to this,
  the preprocessor symbols that activate the fast or asm memcheck helpers
  are moved to mc_include.h
  Platforms with handwritten helpers will also have the memcheck primary
  map defined non static.

* In VEX, auxprogs/genoffsets.c also has to be compiled without lto,
  as the asm produced by the compiler is post-processed to produce
  pub/libvex_guest_offsets.h. lto not producing asm means the generation
  fails if we used -flto to compile this file.

* all the various Makefile*am are modified to use LTO_CFLAGS for
  (most) targets. LTO_CFLAGS is empty when --enable-lto=no,
  otherwise is set to the flags needed for gcc.
  If --enable-lto=no, LTO_AR and LTO_RANLIB are the standard AR and RANLIB,
  otherwise they are the lto capable versions (gcc-ar and gcc-ranlib).

* This has been tested on:
    debian 9.4/gcc 6.3.0/amd64+x86
    rhel 7.4/gcc 6.4.0/amd64
    ubuntu 17.10/gcc 7.2.0/amd64+x86
    fedora26/gcc 7.3.1/s390x

  No regressions on the above.