docs: vendor-neutral remote-backend / TACO onboarding guide

[so0k]

Summary

With local state becoming the default for cdktn init (see open-constructs/cdk-terrain#287), the docs should present remote-state options on equal footing — vendor-neutral, no favourites — instead of presenting HCP Terraform as the default.

What to add

A "remote state options" guide listing choices alphabetically, each with a short equal-footing snippet:

• env0
• HCP Terraform
• Scalr
• Spacelift
• Terrateam
• self-managed: S3 / GCS / AzureRM / http

Key technical notes for the guide

• Spacelift & env0 inject backend config dynamically at run time — projects should emit no backend block (the new cdktn init default is already correct for them).
• HCP / TFE / Scalr use the cloud / remote backend — same construct, only the hostname differs (Scalr is a drop-in TFC alternative).
• Terrateam / self-managed / Scalr BYO-storage use s3 / gcs / azurerm. S3 supports native locking via use_lockfile (no DynamoDB) on TF/OpenTofu 1.10+.
• Standalone / external state servers use the http backend.

Pages to update (currently present HCP as the default)

• https://cdktn.io/docs/create-and-deploy/hcp-terraform#set-up-cdktn-with-hcp-terraform
• https://cdktn.io/docs/create-and-deploy/project-setup#use-hcp-terraform-as-a-remote-backend
• https://cdktn.io/docs/concepts/remote-backends (link target of the new init warning)