feat(cache)!: store a query over 200 bytes as its SHA-256 digest

[allen0099]

Fourth of the 0.4.0 cache-key changes, after #405, #406 and #407.

What changes

• A query component longer than 200 bytes, as encoded in the key, is stored as sha256: plus the full 64-digit hex digest (_QUERY_HASH_THRESHOLD, not configurable), so a client cannot make the query part of a key arbitrarily long.
• The digest is taken after sorting, so sort_query=True still merges reordered long queries.
• A query as sent never looks like a digest: str(QueryParams) / urlencode write : as %3A.
• The path stays readable. clear_path() finds such entries with include_params=True, and the monitoring routes show the digest as query_params (no new field).
• Long paths are left alone.

@cache, build_cache_key() and invalidate() all go through CacheKey.from_request, so they agree.

Docs

• HTTP_CACHING.md and CACHE_FLOW.md (English and zh-TW) describe the rule. They note that Memcached still hashes a whole key over 250 bytes, which a query just under the threshold with a long host or path can reach.
• MIGRATING_0_4.md states the exact threshold.
• changelog.d/269.changed.md.

Tests

tests/test_query_hash.py covers:

• the 200/201-byte boundary, and that the digest is taken over the encoded query;
• hashing after sorting, and that a query cannot pose as a digest;
• extra components after the digest;
• end-to-end hits and monitoring output;
• clear_path with and without include_params;
• invalidate(), including a reordered long query with sort_query=True.

Closes #269