Docs: Improve modules/README.md: Add module overview, selection guidance, and architecture patterns

[gabebatista]

What were you searching in the docs?

Guidance on what Terraform modules are, how to use them, and what architectural patterns they follow.

Is this related to an existing documentation section?

modules/README.md - proposing new sections at the top before module listings.

How can we improve?

The modules README currently jumps directly into listing modules without explaining what they are, how to use them, or the consistent patterns they follow. Adding these foundational sections will help users understand the module system.

Got a suggestion in mind?

1. Add "Understanding Modules" Overview Section (Top of file)

# Terraform Modules

## What Are These Modules?

These are **reusable Terraform modules** for deploying game development infrastructure on AWS. Each module:

- **Deploys a specific service** (Perforce, Jenkins, Unity Accelerator, etc.)
- **Works within your existing VPC** - bring your own network
- **Follows AWS best practices** for security, scalability, and observability
- **Includes working examples** in the `examples/` directory
- **Is independently versioned** and can be used standalone or combined

## How to Use Modules

### Option 1: Use as a Terraform Module Reference
\`\`\`hcl
module "perforce" {
  source = "github.com/aws-games/cloud-game-development-toolkit//modules/perforce?ref=v1.0.0"

  vpc_id     = "vpc-12345"
  subnet_ids = ["subnet-abc", "subnet-def"]
  # ... other variables
}
\`\`\`

### Option 2: Clone and Customize Locally
\`\`\`bash
git clone https://github.com/aws-games/cloud-game-development-toolkit.git
cd cloud-game-development-toolkit/modules/perforce
terraform init
terraform plan
\`\`\`

### Option 3: Use Complete Samples
For integrated multi-module deployments, see [samples/](../samples/).

---

2. Add Common Module Patterns Section

## Common Module Patterns

All modules follow consistent architectural patterns:

### 1. Network Architecture
Every module expects a **3-tier subnet configuration**:
- **Application Subnets**: Where primary services run (ECS tasks, EC2 instances)
- **Service Subnets**: Where supporting services run (RDS databases, ElastiCache)
- **Load Balancer Subnets**: Where NLBs/ALBs are deployed

**Why?** This separation enables fine-grained security controls and network isolation.

### 2. Security Pattern
- **No 0.0.0.0/0 ingress rules** in module code - users explicitly define allowed access
- **Private-first design** - internal services communicate via private DNS
- **User-provided security groups** for external access, module-created groups for internal communication

**Why?** Security is explicit, not assumed. You control who can access your infrastructure.

### 3. DNS Strategy
- **Private Route53 zones** automatically created for internal service discovery
- **Public DNS records** created in user-provided hosted zones (optional)
- **Regional DNS patterns** for multi-region deployments

**Why?** Services discover each other via DNS, not hardcoded IPs.

### 4. Observability
- **CloudWatch log groups** with configurable retention
- **Infrastructure logs** for AWS services (NLB, ALB, EKS)
- **Application logs** for primary services
- **Service logs** for supporting services

**Why?** Centralized logging enables troubleshooting and monitoring.

See [DESIGN_STANDARDS.md](./DESIGN_STANDARDS.md) for complete details.