correcting bug in axis mapping of euler angles

[MZandtheRaspberryPi]

Fixes this issue: #96

Scope
When getting euler angles, they will be returned in a different axis mapping now. A more correct mapping.

Limitations
Users using euler angles in existing code will get their x and z angles flipped when they update to later versions. But, this is correcting a bug and likely users have existing code to remap the output from this library, which they could remove.

Tests
I am using this on a raspberry pi, and tested these changes on my master branch in the fork with a similar commit and rotation is as expected (except signs, but I didn't look into that issue).

Details
I think there is a bug in that for euler angles the z rotation is read from the sensor and put into the x part of the output vector. And the x rotation from the sensor gets put into the z part of the vector. There is also some weirdness with signs, but i didn't look into that.

I think this is because the library reads from the registers in this order here, which is heading, roll, pitch. It then writes heading to X, roll to Y, and pitch to Z here.

I've seen conflicting info out there on whether pitch corresponds to x rotation, or pitch corresponds to y rotation. I've tested with this sensor and this breakout board and the data in pitch register corresponds to X rotation in default axis mapping.

  BNO055_EULER_H_LSB_ADDR = 0X1A,
  BNO055_EULER_H_MSB_ADDR = 0X1B,
  BNO055_EULER_R_LSB_ADDR = 0X1C,
  BNO055_EULER_R_MSB_ADDR = 0X1D,
  BNO055_EULER_P_LSB_ADDR = 0X1E,
  BNO055_EULER_P_MSB_ADDR = 0X1F,

  readLen((adafruit_bno055_reg_t)vector_type, buffer, 6);

  x = ((int16_t)buffer[0]) | (((int16_t)buffer[1]) << 8);
  y = ((int16_t)buffer[2]) | (((int16_t)buffer[3]) << 8);
  z = ((int16_t)buffer[4]) | (((int16_t)buffer[5]) << 8);