Go: robustly handle ambiguous dependency inference

[tdyas]

The dependency inference rules need refactoring since there is duplication currently between the rule applied to go_package targets and the rule applied to _go_ext_mod_package targets (because _go_ext_mod_package does not have a sources field).

Ideas:

• Add a hidden sources field to _go_ext_mod_package that extends the GoPackageSources field used for go_package targets. Merge the rules into a single rule by inferring for GoPackageSources which is now a superclass of the hidden sources field and so the rule should trigger for both GoPackageSources and the hidden sources field.
• Introduce concepts similar to what exists for Python dependency inference (e.g., FirstPartyPythonModuleMapping and ThirdPartyPythonModuleMapping).

[Eric-Arellano]

Updated to instead focus on using ExplicitlyProvidedDependencies.maybe_warn_of_ambiguous_dependency_inference to handle ambiguous dependencies. Relates to https://github.com/pantsbuild/pants/issues/13114, which is the only time I'd realistically expect there to be ambiguous deps.