Update DDG documentation to version 2.9.1

[Calvin-Cheng1]

Description

This branch updates the Detailed Deployment Guide (DDG) to version v2.9.1, reflecting recent improvements and new features in the Stellar Engine.

Summary of Changes

• Version Refresh: Updated documentation from v2.7.1 to v2.9.1.
• Improved Prerequisites: Reorganized the prerequisites into Local Environment and Google Cloud setup, including updated requirements for Terraform (>= 1.8.1) and jq.
• New Networking Stage: Added a dedicated section for IL2/FedRAMP Moderate Stage 2.1 Networking.
• Tenant Management: Added a new Modifying Tenant Projects appendix with step-by-step instructions for adding or removing tenants in an existing deployment.
• Refined Bootstrap Process:
  • Replaced manual service enablement with a dedicated enable_services.sh script.
  • Updated terraform.tfvars samples to align with current module requirements (e.g., pubsub location format).
  • Clarified steps for manual intervention in Assured Workloads folders.
• Enhanced Troubleshooting: Added notes on handling Windows symlink issues and managing billing/quota projects.
• Security Updates: Added guidance on the sa_lockdown.sh script and clarified service account requirements for external billing accounts.
• Naming Conventions: Updated prefix and tenant name constraints to a maximum of 6 characters (down from 7) to ensure global project name uniqueness.

Type of Change

• 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 not work as expected)
• Documentation update

Deployment & Compliance Impact

• Applicable Regimes:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Moderate
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • General / All
• NIST 800-53r5 Controls: (If this PR helps satisfy or modifies control implementations, list them here)

Checklist

Code Quality & Reusability

• My code adheres to the Maximize Reusability principle. I have not redefined common elements and have reused existing base configurations and modules where possible.
• I have checked that no existing module or configuration in modules/ or fast/ can be leveraged for this change.
• My code follows the established naming conventions outlined in documentation/naming-convention.md.

Documentation

• I have updated the README.md of the modified module or blueprint.
• I have added/updated documentation for inputs (variables) and outputs.

Security

• My change adheres to GCP security best practices and the principle of least privilege.
• I have ensured compliance with the targeted regime (FedRAMP High, IL5, etc.).

Testing

• I have tested my changes locally.
• I have included details of my testing in this PR.

Testing Performed

Please describe the tests that you ran to verify your changes.

[LanceWray]

LGTM