Upgrade code base to use C++11

[PeterBowman]

Backward compatibility should not be an issue unless we plan on supporting quite old systems (e.g. Ubuntu Precise, which is reaching its EOL at the time of writing).

[PeterBowman]

Starting from YARP 2.3.72 (scheduled release on 15th November), C++11 will be required for YARP-dependent code (2.3.70 added this prerequisite to compile YARP itself). Cron jobs are currently breaking on upstream devel branch: https://travis-ci.org/asrob-uc3m/robotDevastation/builds/266750949.

PS said errors can be easily solved by switching the adequate compiler option. This issue aims at introducing C++11 features into RD code.

[PeterBowman]

See #109 regarding previous comment. This issue is blocked for that reason.

[PeterBowman]

Question: do we want a smooth transition to C++11 so that unsupported compilers may still build RD (CMake has tools for gradually introducing new language features), or just start using modern C++ constructs straight away?

Remark: Trusty fully supports C++11 via gcc (ref1 + ref2). Same applies for MSVC starting from VS 2015 (ref). The previous question boils down to deciding on which distros are supported by RD.

[jgvictores]

This can be answered from diverse perspectives.

1. YARP. In relation to connecting PC and robots, both parts should agree on protocol. If YARP versions have to match, the device with the oldest OS would be the bottleneck (i.e. the TEO Debian 6.0 affair). Luckily, the low-level of YARP doesn't break compatibility that often. The part that does often change protocol is remote_controlboard, which is used in TEO but not in RD. This means that in RD, YARP versions do not have to match perfectly. We can use the latest stuff on the PC version (which is where we are considering c++11) and maybe older stuff on more limited equipment.
2. Trusty/gcc is good. Regarding Windows, a though experiment would be to think about supporting XP. It seems kind of possible via the 140_xp platform toolset. If not, well, mingw also seems to provide some support.
3. Robot Devastation has always been about playing around, trying to do things we have no idea of how to do!

Given (3), and since we are not breaking backward compatibility in terms of (1) or (2), I'd say "Let's go for it!" and would move on to using modern C++ (as in c++11, not c++17 yet) constructs straight away!