SPM: ZSTDLIB_STATIC_API

[lukaskollmer]

see #4581 for details

context / thoughts:

• SPM already very aggressively favors static linking over dynamic linking, so explicitly defining the library type as static should, effectively have no impact on this
  • not defining it explicitly allows SPM to choose between making the package product a static or dynamic library, which in effect means that it will be a static library, unless it contains resources, which is not the case here
  • if, at some point in the future, we'd want to offer dynamic linking for the Swift package, this would be possible: the convention would be to define a libzstdDynamic package product, whose kind is explicitly set to dynamic
• this PR introduces a second modulemap file
  • looking at the commit history, it seems that the current modulemap file exists solely to support the Package.swift file
  • but: i'm not 100% sure that there isn't some other toolchain/setup somewhere that also depends on the modulemap, so IMO defining a fully separate modulemap for these changes is better than modifying the existing one
  • since the new modulemap is in a dedicated spm directory, it will only be seen if clang is actually pointed at the spm directory (as is now happening in the Package.swift file)
  • any existing code should continue to work as-is, and not see the new modulemap at all (since there will be no existing code that #includes the spm directory