feat: configurable reference frame for a north-referenced azimuth

[camilleRiquet]

Closes #95

Motivation

The azimuth is inconsistent across platforms:

• Android uses TYPE_ROTATION_VECTOR (magnetic-north, east-north-up), so eulerAngles.azimuth == 0 means the device points north.
• iOS starts device motion with the default CMAttitudeReferenceFrame.xArbitraryZVertical: the yaw origin is arbitrary and changes on every sensor (re)start, so the azimuth is not a compass heading.

Details and a reproduction are in #95.

What this PR does

Adds an opt-in RotationSensor.referenceFrame:

enum ReferenceFrame { device, magneticNorth, trueNorth }

RotationSensor.referenceFrame = ReferenceFrame.magneticNorth;

• device (default): behavior unchanged on both platforms - not a breaking change.
• magneticNorth / trueNorth: the azimuth becomes a real compass heading (0 == north).

iOS

Maps the value to the matching CMAttitudeReferenceFrame. CoreMotion expresses a north frame as (north, west, up), whereas this package's documented world is (east, north, up). For north frames the attitude quaternion is rotated
90° about the vertical axis so the emitted orientation matches the package convention and the azimuth stays 0 == north, consistent with Android. The frame is re-applied (sensor restarted) when the value changes mid-stream.

Android

TYPE_ROTATION_VECTOR is already magnetic-north / east-north-up, so all values keep using it. True north would need the local geomagnetic declination (requires a location fix); until then trueNorth behaves like magneticNorth on
Android (documented in the enum).

Notes

• trueNorth on iOS requires location services to be available.
• The default value preserves the previous per-platform behavior.

Testing

Verified on a physical iOS device with magneticNorth: pointing north reads ~0°, east ~90°; the heading is stable under pitch/roll and only changes when rotating about the vertical axis; consistent across cold launches. Android
behavior unchanged.

Disclaimer

Sorry about the previous pull request; I meant to submit a pull request on my fork but made a mistake.

As mentioned in issue #95, I made this change to fix the issue that was discovered, but it might just be that I made a mistake in the initial configuration.

[tlserver]

Thanks for the PR @camilleRiquet ! 🙏
This is a solid contribution and very well implemented. I will accept the PR with some modifications.
Since this work is closely related to issue #12 (adding proper support for a Game Rotation Vector-like sensor on iOS using xArbitraryZVertical), I’d like to handle both together in one go for better consistency and API design.
I’ll merge the core changes and then extend it slightly to also cover the case from #12.
Really appreciate the effort — this is a great improvement for the package!