Use a private namespace for the java dependencies

[shs96c]

The guidelines for rulesets that are not expected to be root modules (such as this one) is that they only contribute to the default maven workspace if their dependencies are required by at runtime by production code that uses the ruleset.

Switching to using a private workspace ensures that this ruleset plays nicely in larger projects.

Also added a lock file to avoid the need to re-run the maven dependency resolution each time the bazel daemon starts.

[gkdn]

@shs96c Have you seen the question/concern in bazel-contrib/rules_jvm_external#916 (comment)

In particular, here we have dependencies like between j2cl and rules_closure. If all j2cl tool dependencies (rules_closure, protobuf, google_common etc) use different maven namespaces how do we deal with with many versions of libs that we end up receiving on the tool side? The problem in user-code <-> library also exists within the context of the rules rule-code <-> library

[IndiTheo]

Haven't looked in it yet, but there's definitely a demand for a clearer resolving separation in nested modules. Had a hard time to fix some build errors. Especially it's frustrating that names are resolved globally, and a deeply nested module's repositories are overridden by root's project repositories with the same name. Maybe it's he desired behavior, but a deeply nested module may not even know the names of the root module's or the sibling modules's repositories.