feature: GitHub Action reusable workflow

[neumachen]

Description

This PR introduces a comprehensive container image build and publishing pipeline using GitHub Actions.

Key Features

• Multi-architecture container builds (linux/amd64, linux/arm64)
• Build caching optimization for faster builds
• Container image signing using Docker Content Trust
• Software Bill of Materials (SBOM) generation
• Image provenance for supply chain security
• Local testing support via act

Workflows

• CI: Runs on PRs to validate container builds
• CD: Builds, publishes and signs images on merges to main/develop and tags
• Reusable composite actions for container builds and signing

Security

• Docker Content Trust for image signing
• SBOM generation for dependency tracking
• Image provenance for build verification
• Privileged container support for multi-arch builds

The pipeline publishes images to both DockerHub and GitHub Container Registry with appropriate tagging and versioning.

Motivation and Context

This change introduces a robust and secure container image pipeline that addresses several key operational and security needs:

1. Broader Platform Support: By adding multi-architecture builds (amd64/arm64), we enable deployment across a wider range of environments, including cloud providers and
   edge devices.
2. Build Performance: Implementation of build caching will significantly reduce build times, especially important for frequent updates and CI/CD efficiency.
3. Supply Chain Security: The addition of image signing, SBOM generation, and provenance tracking provides:
   • Verifiable trust chain for deployed images
   • Comprehensive dependency tracking and vulnerability management
   • Compliance with modern security best practices
4. Developer Experience: Local testing support via act enables developers to validate workflow changes before committing, reducing integration issues.
5. Deployment Flexibility: Dual publishing to DockerHub and GitHub Container Registry provides redundancy and flexibility in deployment options.

These improvements align with industry best practices for container security and distribution while enhancing our development and deployment capabilities.

How Has This Been Tested?

Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.

Screenshots (optional):

Types of changes

• Chore (a change that does not modify the application functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Database Migrations

Checklist:

• I have met the contributing prerequisites
  • Assigned myself to this PR
  • Added the appropriate labels
  • Associated an issue: Issues and Pull Requests README #672
  • Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing
• I have ensured that related documentation is up-to-date
  • Open API docs
  • Code comments (GoDocs / JSDocs)
• I have followed proper test practices
  • Added/updated tests to cover my changes
  • All new and existing tests passed

[superlinkx]

Everything seems in order here. Really looking forward to standardizing the remaining actions into this workflow

[superlinkx]

Might be worth fixing these warnings since they're minor