Add @rules_jvm_external//pin:pin as a convenience script to pin all maven_installs in a workspace

[jin]

e.g. for this repo, there are 7 maven_install external repositories:

//external:unpinned_unsafe_shared_cache_with_pinning
//external:unpinned_regression_testing
//external:unpinned_policy_pinned_testing
//external:unpinned_maven_install_in_custom_location
//external:unpinned_maven
//external:unpinned_manifest_stamp_testing
//external:unpinned_json_artifacts_testing

Running @rules_jvm_external//pin runs the :pin target on every single one of them, making batch-pinning easy.

[joprice]

I ran this locally bazel query //external/... and I see pins of dependencies showing up as well:

...
//external:unpinned_annex_scalafmt
//external:unpinned_annex_proto
//external:unpinned_annex

I didn't realize that they were using the same mechanism, and never thought about how they were being pinned. Choosing one and running bazel run @unpinned_annex//:pin results in a new json pin file being generated at the root of the repo. In the case of this script, will that wind up in the right place or is this a special case?

[jin]

Oh! That's an edge case I haven't thought about. This script currently doesn't handle those unpinned repos correctly, because the maven_install.json are pulled from the dependencies as well. cc @borkaehw

This is one of the reasons why I recommend not sharing maven_install.json to downstream dependents if one is publishing a library. Instead, export the list of artifacts and let downstream dependencies pin their maven_install directly.

[dmivankov]

probably can also add kind(coursier_fetch, ...) filter

[dmivankov]

attr(generator_name, unpinned_maven, ...) is also an option