Migrate from custom migration implementation to golang-migrate

[nutcas3]

This PR replaces the custom database migration implementation with the industry-standard golang-migrate library, providing production-ready features like up/down migrations, database locking, and rollback capabilities.

Changes

Migration Infrastructure

• Installed golang-migrate CLI tool and added library dependency
• Created down migration files for all 7 existing migrations
• Renamed migration files from sequential format (001_xxx.sql) to timestamp format (20240429000001_xxx.up.sql)
• Updated cmd/migrate/main.go to use golang-migrate library instead of custom implementation
• Added support for up, down, and version actions with step-based migration control
• Removed internal/infrastructure/database/migrate.go (custom implementation)

Build & Automation

• Updated Makefile with new migration targets: migrate-up, migrate-down, migrate-version
• Added migration step to CI/CD pipeline (.github/workflows/ci.yml) to run migrations before tests
• Migrations now run automatically in CI to ensure schema consistency

Documentation

• Updated README.md with dedicated Database Migrations section
• Added usage examples for golang-migrate CLI, Makefile targets, and custom migration tool
• Documented migration naming convention and creation workflow

Benefits

• Production-ready migration tool with database locking to prevent race conditions
• Full rollback capability with down migrations for safe schema changes
• Standard tooling with widespread community support and documentation
• Better CI/CD integration with automatic migration execution
• Support for timestamp-based versioning to avoid conflicts in team development

Migration Commands

# Apply all pending migrations
./bin/migrate -dir ./migrations -action up

# Rollback one migration
./bin/migrate -dir ./migrations -action down -steps 1

# Check current migration version
./bin/migrate -dir ./migrations -action version

# Using Makefile
make migrate-up
make migrate-down
make migrate-version

Testing

All existing migrations have been converted and tested. The CI/CD pipeline now runs migrations automatically before executing tests to ensure database schema is up-to-date.