Fix euler angles representation for strain2

[Nicogene]

This PR fixes the Euler angles representation on strain2.

This conversion keep count of this math:

rpy_newSens = rot2rpy(A_R_newSens) = rot2rpy(A_R_oldSens * oldSens_R_newSens) =

= rot2rpy(A_R_oldSens * (newSens_R_oldSens)^T ) =

= rot2rpy(rpy2rot(rpy_oldSens) * (newSens_R_oldSens)^T )

rpy2rot(rpy_oldSens) = B =  0     0     1
                            0    -1     0
                            1     0     0
                            
(newSens_R_oldSens)^T = A =  0    -1     0
                            -1     0     0
                             0     0    -1

C = B*A = 0     0    -1
          1     0     0
          0    -1     0

rpy_newSens = rotm2eul(C, 'XYZ') =  0 -1.5707963267949 1.5707963267949                

That results in this conversion;

x = -z
y = x
z = -y

To be tested on the hardware

[Nicogene]

Unfortunately, this analysis had some flaws and it didn't solve the problem.

Looking at the bno055 datasheet I found out that it is possible to request to bno055 a different axis mapping, we can define it at the startup of the sensor, and then the data that will publish will respect that reference system.

On strain 2 given that:

We have to define the mapping as follows:

We have

AXIS_MAP_CONFIG=00100001=0x21
AXIS_MAP_SIGN=00000111=0x07

Then with this piece of code:

#if defined(STM32HAL_BOARD_STRAIN2)
    // In strain2 we have the P6 configuration reported in the bno055 datasheet
    embot::hw::bno055::write(pImpl->config.sensor, embot::hw::bno055::Register::AXIS_MAP_CONFIG, 0x21, 5*embot::core::time1millisec);
    embot::hw::bno055::write(pImpl->config.sensor, embot::hw::bno055::Register::AXIS_MAP_SIGN, 0x07, 5*embot::core::time1millisec);
#endif

On strain2 we have the p6 configuration

This change allowed us to remove all the conversions around the code, the only conversion that remains is the one regarding the Euler angle that was addressed in robotology/icub-main#701 | #154

[marcoaccame]

ok