[internal] Add [jvm].default_compatible_resolves

[Eric-Arellano]

See #12742.

The idea with default_compatible_resolvse is to let you set the default to >1, whereas default_resolve would force you to only being able to default to one resolve.

While not extremely common, we do suspect there will be some repositories where the majority of your jvm_artifact and java_source targets work with 2+ resolves, and it's only a few targets that diverge.

This should probably be replaced by #13767 eventually.

[ci skip-rust]
[ci skip-build-wheels]

[stuhood]

Although, I'm not sure how desirable this actually is? There's some downside to this PR - it adds another option which is a new layer of complexity. If we think it's reasonable that you'd only ever want to default to 1 resolve, this PR is probably a bad idea.

I think that the general trend is going to be toward all target types having the compatible_resolves field, rather than the resolve field (for the reasons discussed yesterday with @benjyw). But since that is potentially challenging to do before #13882 (since test runners would need native support for doing the cross-product, etc), then we should be thinking of what we're doing with these defaults as a temporary solution.

So: if we think that in the meantime it is easiest to just have the single entry default option, and then only add support for multiple default resolves if users request it, that seems fine to me. Alternatively, if we think that we can replace the single-entry option immediately (by having targets with the resolve field use the first entry in the default list, for example...?), then that seems fine too. But either way, having both default_ options at once seems like overkill.

[Eric-Arellano]

But either way, having both default_ options at once seems like overkill.

Okay, that's fine with me. Let's just have --default-resolve for now as the simplest approach.