[NitinKumar004]

GetMetricData never validated the Period of a MetricStat or MetricDataQuery, and GetMetricStatistics never validated its Period. A huge Period overflowed time.Duration(p) * time.Second. A zero step panicked with a divide by zero, and a negative step produced garbage buckets. For example, a MetricStat Period of 540431955284459520 is a multiple of 60 that wraps to a zero step.

Changes:

• The provider now has ValidatePeriod, which applies the AWS rule from the MetricStat, MetricDataQuery and GetMetricStatistics references. Period is at least 1 and fits an Integer. Valid values are 1, 5, 10, 20, 30, 60 or any multiple of 60. An invalid value returns InvalidArgument with an AWS-style message that names the parameter, for example MetricDataQueries.member.1.MetricStat.Period.
• Provider GetMetricData rejects any non-zero invalid Period. Zero still means the one-minute default for library callers. Buckets are counted in int64 seconds, and a non-positive step returns no points.
• The wire layer checks every query's MetricStat Period and its optional Period through that capability. GetMetricStatistics requires a valid Period. Both map the error to 400 InvalidParameterValue.
• PutMetricAlarm: the EvaluationPeriods * Period lookback check now divides instead of multiplying, so it cannot overflow. It also applies to the MetricStat periods of a metric math alarm, so a huge Period cannot reach the evaluator.

Verified with:

• Regression tests at the provider and wire levels: huge, zero, negative and non-multiple-of-60 periods, plus a client timeout on every request. On the old code, these tests hit the divide-by-zero panic.
• AWS CLI against cloudemu serve: the huge, zero, negative and 61 periods return InvalidParameterValue, and a valid query returns its data.
• Terraform: aws_cloudwatch_metric_alarm (single-metric and metric math) applies, plans with no changes and destroys cleanly.

Closes #1701