Support command line dependency resolution flags

[watt]

Related to #1016 , I'd like to be able to pass arguments to swift package resolve, namely the ones described in the SwiftPM docs under "Using registry for source control dependencies":

One can control if/how SwiftPM should use registry in conjunction with source control dependencies by setting one of these flags:

• --disable-scm-to-registry-transformation (default): SwiftPM will not transform source control dependency to registry dependency. Source control dependency will be downloaded from its corresponding URL, while registry dependency will be resolved and downloaded using the configured registry (if any).
• --use-registry-identity-for-scm: SwiftPM will look up source control dependencies in the registry and use their registry identity whenever possible to help deduplicate packages across the two origins. In other words, suppose mona.LinkedList is the package identifier for https://github.com/mona/LinkedList, then SwiftPM will treat both references in the dependency graph as the same package.
• --replace-scm-with-registry: SwiftPM will look up source control dependencies in the registry and use the registry to retrieve them instead of source control when possible. In other words, SwiftPM will attempt to download a source control dependency from the registry first, and fall back to cloning the source repository iff the dependency is not found in the registry.

I could see this being an argument to the swift_update_packages rule, along the lines of:

swift_update_packages(
    name = "swift_update_pkgs",
    gazelle = ":gazelle_bin",
    generate_swift_deps_for_workspace = False,
    update_bzlmod_stanzas = True,
    registry_scm_transform = "replace-scm-with-registry"
)

Or if it's preferable to not encode that abstraction, being able to pass arbitrary arguments through to the swift command would work here too.

[cgrindel]

For #924, I am working on #957 that as of right now removes swift_update_package. I hope to get it to a good place in the next week or so and then socialize the API change with the community. Most of the functionality in swift_update_package will be obsolete. The question is whether folks like have ability to run swift packages update via Bazel target.

[watt]

There will still be a call to swift package resolve under the hood somewhere, right? I think as long as that's happening, the ability to customize it is my request here, regardless of how that gets exposed.

[cgrindel]

There will still be a call to swift package resolve under the hood somewhere, right?

It will occur somewhere. With the new design, the ruleset does not need to hook into the swift package resolve. So, I removed swift_update_package. It is an open question whether the community likes being able to execute this step via Bazel.

Personally, it feels like we should provide some way to execute this step via Bazel. It helps ensure that the swift package resolve/update use the same version of Swift as the rest of the build.