Further trivially-relocatable support

[Quuxplusone]

This addresses my late-breaking "oops" comment from #1.
I strongly recommend testing "error.cpp" in all modes with GCC and/or your compiler of choice, before merging this one. :)

For example, if the P1144-enabled library (or even Clang trunk with
libc++'s `_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI` defined) reports
that `unique_ptr` is trivially relocatable, then we should use that.

A type which is trivially move-constructible and trivially destructible
but NOT trivially move-assignable, is not considered trivially relocatable
by P1144. `stdx::error` could actually take its trivial codepaths for
such a type, but if anyone actually used such a type with `stdx::error`
today, then when they upgraded to a P1144-enabled compiler, they'd start
getting errors because their type was no longer considered trivially
relocatable. It seems more futureproof to be conservative in the
"zero compiler/library support" codepath, and accept only types that
are 100% trivially copyable. (Move-only types can indeed be trivially
copyable, and I'm not aware of any type that is known to the compiler
to be trivially constructible and destructible without also being
trivially assignable, so I claim this is fine.)

"test.cpp" now compiles with Clang trunk and also my Clang P1144 fork,
in C++14, 17, 20, and 23.

[Quuxplusone]

Darn it, MSVC is unhappy with #elif __has_builtin(__is_trivially_relocatable)...
...okay, I copied libc++'s approach of wrapping that test inside a test of #ifdef __has_builtin. This involved some duplication but isn't too bad.

[charles-salvia]

Looks good to me.