feat(limit-count): add sliding window support for redis-based policies

[sihyeonn]

Description

This PR introduces sliding window support to the limit-count plugin for Redis- and Redis Cluster–based policies while preserving the existing fixed window behavior by default.

• Adds a new window_type option (fixed | sliding) to the limit-count plugin configuration, with fixed as the default for backward compatibility.
• Enforces that window_type = "sliding" is only allowed when the policy is redis or redis-cluster to avoid unsupported combinations.
• Extends the Redis (limit-count-redis) and Redis Cluster (limit-count-redis-cluster) implementations to enforce an exact N requests per rolling time window when window_type is set to sliding.
• Adds test cases for the sliding window behavior in both Redis and Redis Cluster modes (limit-count-redis-sliding.t, limit-count-redis-cluster-sliding.t).
• Updates the English and Chinese limit-count plugin documentation to describe the new window_type option, its behavior, and performance considerations when using sliding windows.

The default behavior remains unchanged for existing configurations that do not specify window_type or continue to use fixed.

Which issue(s) this PR fixes:

Fixes #

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[Baoyuantop]

In high-concurrency scenarios, uniqueness may not be guaranteed. I think we can utilize ngx.var.request_id