Support configuring dependency-resolution repositories in generated settings.xml

[brunoborges]

Summary

Allow setup-java to configure dependency-resolution repositories in the generated Maven settings.xml, so a build can fetch dependencies from one or more repositories beyond Maven Central (for example, GitHub Packages or a private/internal Nexus/Artifactory) without the user hand-writing a settings.xml.

This was prototyped in #813 (now closed as stale). This issue captures the idea with a cleaner, more general scope.

Motivation

Today setup-java writes <servers> entries (credentials) into settings.xml, but it cannot add <profiles>/<repositories> so Maven knows where to download dependencies from. Users who consume artifacts from a private repository must generate or patch settings.xml themselves. Providing first-class inputs for resolution repositories closes that gap.

Note this is the resolution/<repositories> half of multi-repository support; the credentials/<servers> half is handled by the structured mvn-server-credentials input in #1037. A private resolution repository typically needs matching server credentials, so the two are complementary and should compose cleanly.

Proposed behavior

• A new optional input to declare one or more resolution repositories. Prefer a structured, multi-value form (mirroring the mvn-server-credentials style in feat: Add structured multi-server Maven credentials input #1037) so multiple repositories are supported from the start, e.g. a multiline repo-id:repo-url list, rather than single repo-id/repo-url scalars.
• Generate a <profiles> block with <repositories> and a corresponding <activeProfiles> entry.
• Options to control:
  • whether Maven Central is included (default: included),
  • ordering of custom repo(s) vs Central (default: Central first),
  • snapshots enabled/disabled per repository.
• The repository id should be able to line up with a <server> id (from mvn-server-credentials/server-*) so authenticated private repositories work end-to-end.
• Fully backward compatible: when the input is unset, settings.xml is generated exactly as today.

Out of scope

• Mirrors and plugin repositories (could be follow-ups).
• Credentials/<servers> — tracked by feat: Add structured multi-server Maven credentials input #1037 (Add support for multiple servers. #85).

Implementation notes / lessons from #813

• Build on top of (or after) feat: Add structured multi-server Maven credentials input #1037, which refactors generate() in src/auth.ts to take a structured MvnSettingDefinition[]. Extend that structured approach instead of adding many positional optional parameters to generate().
• Add unit tests for the generated settings.xml (Central-only, custom-only, ordering, snapshots on/off, multiple repos).
• Update docs/advanced-usage.md and the README, and rebuild dist/.
• Watch the action.yml indentation (the Extended settings.xml - Profiles with Repo #813 prototype introduced a malformed input block).

References

• Prototype PR: Extended settings.xml - Profiles with Repo #813
• Complementary credentials work: feat: Add structured multi-server Maven credentials input #1037 (Closes Add support for multiple servers. #85)