…#391)

* Eliminate relative paths from the cmake single-module build

* Attempt to reduce length of paths in single module build

When ingesting a `String` instance, `BigString` assumes that the input string has a reasonably efficient UTF-8 view.

Unfortunately, that is very much not the case when the input happens to be backed by a bridged NSString object — it appears that in this case, the ingester loop invokes some operation(s) with linear complexity in the size of the entire input, rendering the ingester’s overall complexity quadratic.

The BigString ingester is only expected to operate within a single chunk at the time. It’s unclear precisely which operation triggers the quadratic behavior; ideally we should figure it out and resolve it with a more targeted fix.

In the meantime, a blunt stopgap fix is to force-transcode the input string to UTF-8 at the time the ingester is initialized. This unnecessarily wastes some (temporary) memory on holding the transcoded string, but it avoids the quadratic cliff.

[BigString] Fix accidentally quadratic `BigString.init`

add 'final' keyword to class

To repair the swift-corelibs-foundation build on WebAssembly, we need to
add support for Wasm targets to swift-collections' CMake build system.

[CMake] Add support for WebAssembly target architectures

[concurrency] conform Deque.Iterator to unchecked-Sendable

Add more file in Sources/BitCollections/CMakeLists.txt

Lowercasing `CMAKE_SYSTEM_NAME` to find the name Swift uses for a platform
is not guaranteed to work.  Instead, use the `SWIFT_SYSTEM_NAME` variable,
which lets us override the name when building the Static SDK for Linux.

Fixes #420.

[Build] Use `SWIFT_SYSTEM_NAME` rather than just lowercasing.

(cherry picked from commit 7d18b37)

# Conflicts:
#	cmake/modules/SwiftSupport.cmake

[CMake] Handle riscv64