Use distinct Swift modules for Apple crypto static archive

[vcsjones]

This is the "quicker" fix for #128867 that should work. It uses a different module name between the dylib and static archive so the Swift classes can coexist in the same proces for CoreCLR and NAOT. It does not permit two NAOT libraries in the same app. It is largely this suggestion from @MichalStrehovsky

I wonder if we could name these classes differently when building the static library libSystem.Security.Cryptography.Native.Apple.a (used for native AOT and single file deployments) vs when building the shared library libSystem.Security.Cryptography.Native.Apple.dylib (used otherwise).

Using different module names between dylib and archives results in different exported names for the classes:

dylib:  __DATA__TtC17pal_swiftbindings7HashBox
dylib:  __DATA__TtC17pal_swiftbindings12X25519KeyBox

static: __DATA__TtC24pal_swiftbindings_static7HashBox
static: __DATA__TtC24pal_swiftbindings_static12X25519KeyBox

So they should be able to coexist in the same process. A longer term solution on how to resolve this broadly for loading multiple NAOT libraries in the same process is something that will be a follow up, but I think this unblocks the SDK's needs.

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Updates the Apple crypto native library build to compile the Swift bindings into two distinct object files (shared vs. static) with different Swift module names, so both variants can be loaded into the same process without Swift/ObjC class registration name collisions.

Changes:

• Split pal_swiftbindings.swift compilation into two outputs: pal_swiftbindings_shared.o and pal_swiftbindings_static.o.
• Pass distinct -module-name values to swiftc for shared vs. static builds.
• Wire the appropriate Swift object file into each CMake target (SHARED vs. STATIC).

Show a summary per file

File	Description
src/native/libs/System.Security.Cryptography.Native.Apple/CMakeLists.txt	Builds Swift bindings twice with distinct module names and links the correct object into the shared dylib vs. static archive to avoid class-name collisions.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 1

[vcsjones]

Closing in favor of #128917.