Moves withResolver into DIKit as a Debug-only SPI, so tests hosted in an app can use the app's copy of DIKit, and adds the DIKitDynamic product.
InjectSettings.withResolver(_:operation:) now lives in DIKit instead of DIKitTesting. It is compiled in Debug builds only and marked @_spi(Testing): tests call it after @_spi(Testing) import DIKit, app code that imports DIKit normally cannot call it, and Release builds contain neither the method nor the task-local override that InjectSettings.resolver reads. Replace import DIKitTesting with @_spi(Testing) import DIKit wherever withResolver is called.
DIKitTesting links DIKit statically, so a test bundle that linked it carried its own copy of DIKit. In tests hosted in an app, withResolver installed the resolver in that copy, and the app kept resolving from its own container. With withResolver in DIKit, such a test bundle links the same DIKit product as the app and leaves DIKitTesting out. DIKitTesting now contains only the .resolver Swift Testing trait, which is Debug-only as well and reaches only code linked into the test binary, as in the tests of a Swift package.
DIKitDynamic is the same library built as a dynamic framework. Link it into every binary of a process, such as an app and its embedded frameworks or an app and the test bundle it hosts, to guarantee a single copy of DIKit and a single shared container.