Issue Description:

Currently, there is no (good/simple) way to have a SwiftPM Package depend on a binary library that is not a system library.

See here for an MWE.
A partial workaround was proposed in Slack.

Use case: use a custom-built cryptography library; ship it as part of the developed application or library.

I'm admittedly mostly naive in the issues of native compilation, but the way I understand it, the current workflow (system libraries aside) is

1. build the dependency package and
2. put the resulting .dylib in .build/debug to link against.

This should be easy to replace by

1. copy the dependency library into .build/debug to link against.

From what I can tell, replacing the current command <name.dylib> (which recursively compiles the library to create .build/debug/libname.dylib) with the following should already be enough:

"<name.dylib>":
    tool: shell
    description: "Linking name"
    inputs: ["/path/to/dependency/my.dylib"]
    outputs: ["/path/to/package/.build/debug/libname.dylib", "<name.dylib>"]
    args: ["cp", "/path/to/dependency/my.dylib", "/path/to/package/.build/debug/libname.dylib"]

On the frontend, SwiftPM would have a Dependency protocol which the current Package and a new Binary(library: String, header: String, ...?) would implement; Package.dependencies would then be of type Array<Dependency> (instead of Array<Package>).

Relates to SR-648 and SR-2048.