Update Maven rules to support platform profiles and Windows deployment

[dmitrii-ubskii]

What is the goal of this PR?

We update deployment and assembly rules to be invokable on Windows, and to support per-platform profiles in pom.xml.

Per-platform overrides expects a dict of bazel labels to a JSON-encoded dictionary of platform to maven coordinates. Supported OS: windows, linux, mac Supported architectures: x86_64, aarch64 Ex.:

assemble_maven(
    ...
    profile_overrides = {
        ":bazel-dependency": json.encode({
            "windows-x86_64": "org.company:dependency-windows-x86_64:{pom_version}",
            "linux-aarch64": "org.company:dependency-linux-aarch64:{pom_version}",
            "linux-x86_64": "org.company:dependency-linux-x86_64:{pom_version}",
            "mac-aarch64": "org.company:dependency-macosx-aarch64:{pom_version}",
            "mac-x86_64": "org.company:dependency-macosx-x86_64:{pom_version}",
        })
    }
)

What are the changes implemented in this PR?

• improve portability of maven assembly and deployment rules,
• add the ability to specify per-platform profiles.

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.