update deprecations for C++14

fix:

…/dynamic-graph/src/dgraph/entity.cpp: In member function ‘void dynamicgraph::Entity::sendMsg(const string&, dynamicgraph::MsgType, const string&)’:
…/dynamic-graph/src/dgraph/entity.cpp:212:52: warning: ‘void dynamicgraph::Logger::sendMsg(std::__cxx11::string, dynamicgraph::MsgType, const string&)’ is deprecated: use stream(type, lineId) << msg [-Wdeprecated-declarations]
   logger_.sendMsg("[" + name + "]" + msg, t, lineId);
                                                    ^
In file included from …/dynamic-graph/include/dynamic-graph/entity.h:18:0,
                 from …/dynamic-graph/src/dgraph/entity.cpp:13:
…/dynamic-graph/include/dynamic-graph/logger.h:225:3: note: declared here
   sendMsg(std::string msg, MsgType type, const std::string &lineId = "");
   ^~~~~~~

ref. #58

[CMake] upgrade C++ standard from 11 to 14

To fix build issues on dependent packages on 16.04

add doc/make CommandVoid 5-8

ref. https://github.com/stack-of-tasks/dynamic-graph/issues/36

Make switch to std::shared_ptr easier

This reverts commit 62765608.
as this is breaking on boost < 1.73

[CMake] set RPATH for plugins

to fix debian packages creation on ROS buildfarm:

00:12:11 dpkg-shlibdeps: error: cannot find library libtracer.so.4.3.1 needed by
debian/ros-noetic-dynamic-graph/opt/ros/noetic/lib/dynamic-graph-plugins/libtracer-real-time.so.4.3.1
(ELF format: 'elf64-x86-64' abi: '0201003e00000000'; RPATH: '')

[CMake] DYNAMIC_GRAPH_PLUGINDIR is now relative

Tracer: Adding lock to make it threadsafe

For now, the plugins can only be loaded from python, so we just need the
wrap.so to be able to find its plugin.so. For this, there is no need for
a unique hard-coded absolute path to provide an RPATH to
libdynamic-graph.so.

And actually, that RPATH was not even set.

ref. https://github.com/boostorg/test/commit/235acea2fa4b1eb7580acbfcce94d696c86bb207#diff-9131a06d2a1a6d0c877c9b7909acbbde

Using both ADD_PROJECT_DEPEDENCY & FIND_PACKAGE for Boost breaks uses of
${Boost_LIBRARIES}: only the last call to one ore the other is taken
into account.

I suggest to use ${Boost_LIBRARIES} for exported ones, and eg.
${Boost_UNIT_TEST_FRAMEWORK_LIBRARY} for the private ones.