[venkata-kishore]

Moves the build and release workflows from oss-parent into reusable workflows here, so every BonfireTrunk Maven library runs the same ones and a fix lands everywhere at once.

• maven-build.yml: builds and tests a library on pull requests with a read-only token and no secrets. It runs ./mvnw -B -ntp verify by default; the optional maven-args input replaces verify for a library that needs a different build.
• maven-release.yml: the release job from oss-parent, now publishing to GitHub Packages as well as Maven Central. When a Release X.Y.Z PR is merged into prime, one Maven run builds and signs the artifacts, uploads them to Central (deploy) and sends the same signed files to https://maven.pkg.github.com/<owner>/<repo> (deploy:deploy with altDeploymentRepository). GitHub Packages authenticates with the job's GITHUB_TOKEN, so the caller grants packages: write and no new secret is needed. On a manual re-run, each registry that already has the version is skipped: Central is checked on repo1, GitHub Packages through the package versions API. It declares the four release secrets it needs, so a library passes exactly those.
• cla.yml: runs the agreement check on this repository's own pull requests, so the cla / check check can be required here too.
• The README lists the new files and shows the three caller files a library adds. With a caller job id of build, the build check is named build / build.

Checked locally: all workflows and the README examples parse, and actionlint (with shellcheck) reports only the unknown ubuntu-26.04 runner label, which GitHub already runs our builds on, and the intentional word splitting of the Maven arguments. Deploying to Central and to a second repository in one run was tried against a local file repository: both received byte-identical artifacts and signatures.

Once this is merged, oss-parent switches to callers in its own PR, and that PR's build exercises maven-build.yml.