utils: test-js: use heredoc to avoid oneline only for js code
jsvm: handle exceptions that throwed from js code
jsvm: allow to change values inside *FOR js code

Just return new value and it will be updated, if you don't want to
update it, just return previous value.
Exampled added into test-js.sh.
utils: test-js: check keys after updating
utils: test-js: adopt it to nc.openbsd

On my machine I have nc.traditional and it have different behaviour
about -q option in comparison with nc.openbsd version.

I suppose that by the same reason CI build are broken.

CI: https://travis-ci.org/azat/boostcache/builds/24907449
build: move generation of config for cpack into GeneratePackage macro
build: drop extra BOOSTCACHE_BINARY_DIR variable
build: make BOOSTCACHE_BUILD_DIR configurable
build: add different sanitizers: {thread,address,memory}

- SANITIZE_THREAD:
    Since gcc 4.8.x and newer version of clang support this feature, and it
    must be faster then valgrind, and also it must be compitable with c++11
    threads API unlike valgrind drd/helgrind.
- SANITIZEADDRESS
- SANITIZEMEMORY:
    According to http://clang.llvm.org/docs/MemorySanitizer.html:
      "MemorySanitizer requires that all program code is instrumented. This also
       includes any libraries that the program depends on, even libc. Failing to
       achieve this may result in false reports"
      ...
      "In the case when rebuilding all program dependencies with MemorySanitizer is
       problematic, an experimental MSanDR tool can be used. It is a DynamoRio-based
       tool that uses dynamic instrumentation to avoid false positives due to
       uninstrumented code. The tool simply marks memory from instrumented libraries
       as fully initialized"

    But MSanDR requres too much, and will not always works, therefore this is
    not a good idea to use it now.
    I use something like this to test using MSanDR:
      ROOT=$(dirname $0)
      DYNAMORIO=$ROOT/../../../dynamorio/exports
      DRMEMORY=$ROOT/../../../drmemory/.cmake/exported

      MSAN_OPTIONS='verbosity=1:sleep_before_dying=10' \
      MSAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4 \
      LD_LIBRARY_PATH=$DYNAMORIO/ext/lib64/release/:$DYNAMORIO/lib64/release/:$DRMEMORY/drmf/lib64/release/:$ROOT \
      LD_USE_LOAD_BIAS=1 \
      $DYNAMORIO/bin64/drrun -v -64 -c $ROOT/libmsandr.so -- \
      $*
build: fix building boostcache with clang and c++ headers from gcc-4.9

See http://reviews.llvm.org/rL201729
utils: sanitizers: script to compile server and run simplest tests under it

See also c9d97a6cc1c90ad5ac009131f6b1a6f7379c3216 ("build: add different
sanitizers: {thread,address,memory}") this can give more information.
utils/run_tests: kill with INT signal instead of TERM (works with sanitizers)

Seems that under sanitizers TERM signal not received by the server.
travis-ci: run sanitizers
utils/test-js: return back value to the server

Otherwise you will get "undefined" next time you are querying the key.
I don't think that this is _optimal_ but simple, so just leave this as
is for now.
build: run sanitizers after all other targets

Since it need to regenerate makefiles and as a consequence cmake cache
will be updated.
utils/sanitizers: drop CMakeCache from the same as CMakeLists to avoid errors

If somebody build project without extra subdir for cmake generated stuff,
then current script will pick up cache from the same directory where
CMakeLists.txt is, and will fail because of cached *COMPILER* variables.
So just drop it and that's it.

Error messages like this:
  You have changed variables that require your cache to be deleted.
  Configure will be re-run and you may have to reset some variables.
  The following variables have changed:
  CMAKE_CXX_COMPILER= clang++
  CMAKE_C_COMPILER= clang

And also because of this, detection of the compiler family will be wrong and
wrong flags will be checked (gcc and clang have different needs for thread
sanitizer).

CI: https://travis-ci.org/azat/boostcache/builds/24924628
build: add LTO (linker time optimization) for {release,distribution}

Some numbers:
============
component       after      before
- server        4.2M       12M
- deb package   1.4M       3.0M
- time of make  0m22.879ss 0m13.088ss
- readelf -s    4365       4588

$ for i in boostcached boostcached-nolto; do
    readelf -S $i | \
    gawk '{if ($1 ~ /^[0-90-f]+$/ && name ~ /^\./) { printf "%s %.0f\n", name, strtonum("0x" $1); } name=$(NF > 3 ? NF-3 : ""); }' | \
    sort -k1,1 >| symtab.${i/boostcached/}
  done
$ join -j1 symtab.nolto symtab | \
  awk '{diff=($3-$2)/1024; if (diff < -10) { printf "%18s: %.3fKB\n", $1, diff}; total += diff; } END { printf "Total: %.fKB\n", total }'
    .debug_aranges: -12.406KB
       .debug_info: -2003.333KB
       .debug_line: -195.751KB
        .debug_loc: -868.711KB
     .debug_ranges: -290.578KB
        .debug_str: -3476.869KB
           .dynstr: -62.563KB
           .dynsym: -10.195KB
             .text: -62.641KB
  Total: -6951KB

As you can see, results are pretty cool.
And as for -fwhole-program I decide not to turn it on for now, because
this must be done only for final binaries, while I wanted to make this
patch as simple as it can be. (Even if we can reduce binary sizes with
-fwhole-program)

But this LTO stuff sometimes are a bit tricky and can break some stuff,
for more information about tricky stuff you could look into
http://thread.gmane.org/gmane.linux.kbuild.devel/8586/focus=8629 this
lkml post.
build: use OVERWRITE for AddCompilerFlags macro (updated)

New AddCompilerFlags() is more generic, which will allow not to check
flags for not you build type, but if you want to you must use FORCE, but
this patch don't add this, so it change the behaviour which compiler
flags will be validated.
And what about OVERWRITE, this is used if you need to pass flags for
linker stage not the compiler one.
build: pass needable options for linker stage for sanitizers
build: fix LTO for clang

Firstly clang needs in gold linker, so add a wrapper for it.
And this is not the end, because gold linker needs in plugin otherwise
it can't read object files that generated by $(clang -flto), seems that
it not generate GIMPLE as gcc, instead it have IR (Intermediate
Representation).
This plugin will be added automatically for ld when needed, but not for
ar, so when the archive libs will be introduced we will need to pass it
manually.

For libraries (dynamic and static):
---------------------------------
  (They are not exist for our project for now, but jsut in case)

  If you will have different version of this plugin and compiler, (since
  clang will read only /usr/lib/LLVMgold.so and not look into version)
  you will get segmentation fault for gold linker (see also [1]):
  (gdb) bt
     #0  0x00007f368150e948 in llvm::AttributeImpl::getKindAsString() const () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1
     #1  0x00007f368150e961 in llvm::Attribute::getKindAsString() const () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1

  With 3.3 version of clang I couldn't get build to work, because of errors for
  archive libraries and it's symtab:
  - no archive symbol table (run ranlib)
    This was solved by using llvm-ranlib and plugin for ar
    And also if you just use llvm-ar, then llvm-nm will segfault.
  - malformed archive header name at {8,138}
    This was solved by upgrading llvm/clang to 3.4 from experimental
    debian distribution.

And here is some numbers what we have now:
------------------------------------------
  component:      gcc lto       clang lto
  deb package     1.3M          1.6M
  boostcached     4.1M          7.4M

  $ readelf -S boostcached-gcc   | gawk '{if ($1 ~ /^[0-90-f]+$/ && name ~ /^\./) { printf "%s %.0f\n", name, strtonum("0x" $1); } name=$(NF > 3 ? NF-3 : ""); }' | sort -k1,1 >| symtab.gcc
  $ readelf -S boostcached-clang | gawk '{if ($1 ~ /^[0-90-f]+$/ && name ~ /^\./) { printf "%s %.0f\n", name, strtonum("0x" $1); } name=$(NF > 3 ? NF-3 : ""); }' | sort -k1,1 >| symtab.clang
  $ join -j1 symtab.gcc symtab.clang | awk '{diff=($3-$2)/1024; if (diff < -10) { printf "%18s: %.3fKB\n", $1, diff}; total += diff; } END { printf "Total: %.fKB\n", total }'
         .debug_abbrev: -84.449KB
        .debug_aranges: -11.188KB
           .debug_line: -20.646KB
            .debug_loc: -771.084KB
               .rodata: -11.891KB
               .strtab: -32.161KB
    Total: 3359KB

[1] https://retrace.fedoraproject.org/faf/problems/1368472/