Optimize SWAP macro by using move semantics.

[Ivorforce]

Move semantics help make code faster by changing ownership rather than copying objects. In the case of SWAP, a maximum of 3 copies can be avoided, if the underlying objects have corresponding constructors and assignment operators. The current implementation forces the compiler to copy the object for each assignment:

template <typename T>
 inline void __swap_tmpl(T &x, T &y) {
 	T aux = x;  // copy assignment
 	x = y;  // copy assignment
 	y = aux;  // copy assignment
 }

Recently, we starting to introduce move semantics into the codebase. In particular, there was #100239 for String, Vector and CowData. Hopefully, sometime in the future, we'll get similar move constructors and assignments for Variant. The SWAP macro should be ready to accelerate these semantics.

The implementation of std::swap on my machine (macOS) looks like this:

template <class _Tp>
inline _LIBCPP_HIDE_FROM_ABI __swap_result_t<_Tp> _LIBCPP_CONSTEXPR_SINCE_CXX20 swap(_Tp& __x, _Tp& __y)
    _NOEXCEPT_(is_nothrow_move_constructible<_Tp>::value&& is_nothrow_move_assignable<_Tp>::value) {
  _Tp __t(std::move(__x));
  __x = std::move(__y);
  __y = std::move(__t);
}

It could be trivially re-implemented in Godot as such:

template <typename T>
inline void __swap_tmpl(T &x, T &y) {
	T aux(std::move(x));
	x = std::move(y);
	y = std::move(aux);
}

However, since both std::swap and std::move are defined in <utility> (i.e. the include is needed anyway), I see no reason to reinvent the wheel (except maybe to make it constexpr?).

[hpvb]

LGTM, if we start seeing very strange compiler errors when this is misused we could revert to the "manual version" but I don't think that is likely in this case. std::swap() seems like a reasonable choice here.

[akien-mga]

Thanks!