`GLM_FORCE_QUAT_DATA_XYZW` is misleading and misdocumented

[glebov-andrey]

Hi!

The name GLM_FORCE_QUAT_DATA_XYZW suggests, and the manual claims, that the macro affects data layout

glm/manual.md

Lines 754 to 756 in 6f14f47

	### <a name="section2_21"></a> 2.21. GLM\_FORCE\_QUAT\_DATA\_XYZW: Force GLM to store quat data as x,y,z,w instead of w,x,y,z
	By default GLM stores quaternion components with the w, x, y, z order. `GLM_FORCE_QUAT_DATA_XYZW` allows switching the quaternion data storage to the x, y, z, w order.

... but this is wrong.
The default layout is actually x, y, z, w (unless GLM_FORCE_QUAT_DATA_WXYZ is defined - note *W*XYZ, not XYZ*W*), while GLM_FORCE_QUAT_DATA_XYZW only affects the constructor's parameter order.

It seems that while fixing #1228, #1216 changed the macro from GLM_FORCE_QUAT_CTOR_XYZW (logically correct name) to GLM_FORCE_QUAT_DATA_XYZW instead of changing the definition of qua::wxyz() to use GLM_FORCE_QUAT_CTOR_XYZW.
This issue was also noted here (dcb8496#commitcomment-138487026).

Aside from just being confusing, this also amounts to a breaking change in 1.0.1 for users who defined GLM_FORCE_QUAT_CTOR_XYZW expecting it to affect the constructor's parameter order (although in that case qua::wxyz() was broken).

I'm not exactly sure how this should be fixed though. Perhaps the best option is to change the macro back to GLM_FORCE_QUAT_CTOR_XYZW, fix the documentation, and emit a compiler error when GLM_FORCE_QUAT_DATA_XYZW is defined. Or just support both macros, and check for mismatches during preprocessing.

BTW, thanks for reverting the change that coupled glm::qua's data layout to its constructor's parameter order - that blocked upgrading from 0.9.9.8 for a while!