qua::wxyz() uses incorrect ifdef check

[Eearslya Sleiarion]

qua has a couple of defines which allow the end user to configure the order in which the data is stored, as well as a separate define to change the order the constructor uses: GLM_FORCE_QUAT_CTOR_XYZW.

Historically, changing the order of the constructor caused major breakage across all of GLM, because the rest of the library's internal functions weren't prepared to deal with the constructor being in a different order. It looks like a new static function qua::wxyz has been introduced to rectify this problem. The function seems to be a way to implicitly swizzle the arguments if the constructor has had its arguments reordered.

However, qua::wxyz does not check for the presence of GLM_FORCE_QUAT_CTOR_XYZW, it checks for the presence of GLM_FORCE_QUAT_DATA_XYZW. Since these two defines are now separate, it's possible for the data to be WXYZ while the constructor is XYZW, and thus the function will still assign the values to the wrong places.

// detail/type_quat.inl L156
	template <typename T, qualifier Q>
	GLM_CONSTEXPR qua<T, Q> qua<T, Q>::wxyz(T w, T x, T y, T z) {
#	ifdef GLM_FORCE_QUAT_DATA_XYZW
		return qua<T, Q>(x, y, z, w);
#	else
		return qua<T, Q>(w, x, y, z);
#	endif
	}