Use constexpr inside yarp

[Nicogene]

We could replace all the defines around yarp with constexpr, but more important we can use the constexpr functions.

The constexpr functions has the limitation of that they have to have only one return statement and they have to handle data that is defined compile time.

The constexpr variables and functions are defined compiled time and put in read-only memory.
More computation we move from the run-time to the compilation more the code will run faster!
For example functions of conversion between measurement units should be constexpr.

[PeterBowman]

I was thinking about moving vocab preprocessor definitions to constexpr functions. Care should be taken to avoid duplicate definitions, and perhaps vocabs could live in a namespace instead of in the global scope (although some of them are placed inside enums).

[Nicogene]

First step: #1764

[Nicogene]

After merging #1764 the next step is to change all the

#define MY_VOCAB yarp::os::makeVocab('m','y','v')

in

constexpr int32_t MY_VOCAB = yarp::os::makeVocab('m','y','v');

[drdanz]

I suggest to add in numeric.h

namespace yarp {
namespace conf {
// [...]
typedef std::int32_t vocab32_t
}
}

and to return yarp::conf::vocab32_t in these functions

This will allow us (one day) to change easily from signed to unsigned and will also save us from big issues in case, one day, we wanted to to have a 64 bit vocab

[Nicogene]

I noticed reviewing #1924 that PAD_BYTES could become a constexpr function once we will adopt c++14.
Now I get this warning:

warning: variable declaration in a constexpr function is a C++14 extension [-Wc++14-extensions]
            const size_t rem = len % pad;