chore(common): rename ServiceSavingsPlans -> ServiceSavingsPlansAll + add SavingsPlansPlanTypes() helper #786

Summary

The Savings Plans service-type slug system is confusing on first read:

ServiceSavingsPlans            ServiceType = "savingsplans"              // umbrella
ServiceSavingsPlansCompute     ServiceType = "savings-plans-compute"     // specific
ServiceSavingsPlansEC2Instance ServiceType = "savings-plans-ec2instance" // specific
ServiceSavingsPlansSageMaker   ServiceType = "savings-plans-sagemaker"   // specific
ServiceSavingsPlansDatabase    ServiceType = "savings-plans-database"    // specific

Two sources of confusion:

1. The hyphenation differs (savingsplans vs savings-plans-*) -- deliberate per issue Normalize 'savings-plans' vs 'savingsplans' identifier across frontend + backend cloud-commitments-platform#7 to avoid a SQL migration, but the Go identifier ServiceSavingsPlans doesn't signal that this one is a sentinel/umbrella.
2. The fan-out from umbrella to 4 plan types is implicit (planTypesForParams does it inside getSavingsPlansRecommendations) -- a reader scanning GetAllRecommendations doesn't see "this expands to 4 calls".

Scope (cosmetic-only, NO SQL migration)

Three changes, all in pkg/common/types.go + call sites:

1. Rename ServiceSavingsPlans -> ServiceSavingsPlansAll. The string value stays "savingsplans" (DB column unchanged). Same for any test fixtures, frontend constants, etc. Goal: at every call site, the reader can tell at a glance "this is the umbrella sentinel, not a specific plan type".

2. Add func SavingsPlansPlanTypes() []ServiceType returning the 4 per-plan-type slugs in canonical order (Compute / EC2Instance / SageMaker / Database).

3. Update IsSavingsPlan to match the renamed identifier (no behaviour change).

Out of scope

• Renaming the DB column value "savingsplans" -- explicitly avoided per issue Normalize 'savings-plans' vs 'savingsplans' identifier across frontend + backend cloud-commitments-platform#7
• Changing the per-plan-type slug strings -- they're already in DB columns and the frontend uses them
• Eliminating the umbrella -- needs a 1 row -> 4 rows migration that isn't lossless and was rejected at Normalize 'savings-plans' vs 'savingsplans' identifier across frontend + backend cloud-commitments-platform#7
• Touching the legacy "savings-plans" (hyphenated) mapper in internal/purchase/execution.go -- that handles pre-#85 JSONB blobs and stays as-is

Acceptance criteria

• ServiceSavingsPlans renamed to ServiceSavingsPlansAll across the Go codebase
• SavingsPlansPlanTypes() helper added with a unit test asserting the 4-element canonical order
• IsSavingsPlan still recognises all 5 slugs (4 per-plan-type + 1 umbrella)
• Tests pass (incl. the codec test that round-trips the umbrella string "savingsplans")
• DB schema unchanged; persisted rows still read/write as "savingsplans" for the umbrella

Cross-references

• Issue Normalize 'savings-plans' vs 'savingsplans' identifier across frontend + backend cloud-commitments-platform#7 -- locked in "savingsplans" (no hyphen) as the canonical DB-column value to avoid migration
• PR fix(recommendations): add Savings Plans to GetAllRecommendations fan-out (closes #784) #785 (closes fix(recommendations): SP recs never reach Opportunities list -- missing 6th goroutine in GetAllRecommendations fan-out #784) -- recent fan-out fix; passes ServiceSavingsPlans to GetRecommendationsForService which is exactly the call site that benefits most from the rename
• PR feat(commitmentopts): probe Savings Plans offerings live (closes #108) #569 -- adds live SP commitment-option probing using the same slugs (unaffected by the rename if it merges after; merge order doesn't matter)