Fix alignment issues when allocating in AtomicWaitQueue

[grynspan]

This change ensures that AtomicWaitQueue allocates its inner queues in an aligned fashion even when the compiler does not support the C++17 "over-aligned new" feature, and avoids using new anyway since it might be overridden by something else in the process.

On some platforms, the compiler does not support the C++17 "over-aligned new" feature. Allocating an instance of type T with new T() will produce a naturally-aligned pointer, which appears to be insufficient for use with AtomicWaitQueue on said platforms. Windows and Android in particular have been identified as affected.

The solution is to explicitly call std::aligned_alloc() (or, if the type's size is somehow not a multiple of its alignment, std::malloc()) and to use placement new to initialize the new value. Destruction is accomplished by directly calling the type's destructor and then passing the pointer to std::free().

Since swift_slowAlloc() and swift_slowDealloc() handle alignment already and are the preferred allocation mechanisms in Swift, sub them in for std::aligned_alloc() and std::free() above.

This fix has the added benefit of avoiding the global operator new, which can be overridden by other code in the process. If the global operator new is overridden in such a way that it re-enters the Swift runtime, sadness will result.

[grynspan]

@swift-ci please test

[grynspan]

There are a couple of typos in this PR but they don't affect the correctness of the code, so I'm going to wait until the current CI builds complete before fixing.

[grynspan]

@swift-ci please test

[rjmccall]

LGTM

[mikeash]

LGTM. I'd like to suggest different names for the new functions. The "slow" in the existing functions is kind of leftover so I'd suggest we not bring that forward, and I'd like to make the names more clear about doing the same thing as new/delete. Perhaps swift_cxxNew and swift_cxxDelete?

[grynspan]

@swift-ci please test

[grynspan]

Mike and I discussed and settled on swift_cxx_newObject() and swift_cxx_deleteObject() for maximum unambiguity.

[grynspan]

@swift-ci please test windows

[compnerd]

This definitely is a step in the right direction! This should save us from the global operator new replacement shenanigans and also module specific allocators.

[grynspan]

Holding for @compnerd to approve. Oh, he did. Thanks!

The Windows build failure appears unrelated to this PR. Will try a rebuild in case it's been resolved on main, but otherwise I don't think it holds up merging.

[grynspan]

@swift-ci please test windows

[grynspan]

The Windows issue is indeed present on main, so merging!