Swift: unable to use any of the advanced/static-linking-only APIs

**Describe the bug**
The Swift interface exposed via the `libzstd` target defined in Package.swift currently does not include any of the static-linking-only functions, and there is no way for a swift app/package depending on zstd to enable these APIs, even if zstd ends up getting statically linked.

**To Reproduce**
Add zstd as a dependency to a swift package, and try to use one of the static-only APIs (eg `ZSTD_isFrame`)

**Expected behavior**
Clearly it should be possible to always use the full API, regardless of which language it is being bridged into (provided you're statically linking the library).

**Possible Solutions**
There are multiple ways this could be resolved:
- we could introduce a shim header that sets the `ZSTD_STATIC_LINKING_ONLY` define and then includes zstd.h, and change the modulemap to include the shim header instead of directly including zstd.h
- this would resolve the issue, but unconditionally requiring static linking via the modulemap seems like a bad idea, since it'd also affect other (non-swift-package-related) situations where the modulemap is used
- we could introduce a second, separate modulemap that is used only by the SPM package (i.e., the Package.swift file)
- this approach would ensure that any existing code / setups that use the modulemap will continue to work unchanged

(Note: simply adding `.define("ZSTD_STATIC_LINKING_ONLY")` to the `cSettings` array in Package.swift does not work, since flags defined in this way only affect the compilation of the code, but do not affect the clang importer.)

**Additional context**
Tbh i have no idea if any / which other things (besides Swift's clang importer) use the modulemap file, and it might actually be safe to simply modify it in place, but i'm not comfortable doing that and think it'd be a bad idea, so adding the secondary, Swift-only one seems like the best approach.