Nginx decodes an URL-encoded slash (%2F) into a real '/' in $uri before
route matching, so a request like /v1/te%2Fst/products/electronics/list is
seen as /v1/te/st/products/electronics/list and fails to match a route with
path parameters such as /v1/:id/products/:type/list.

Add an opt-in apisix.preserve_encoded_slash option. When enabled, the route
matching uri is rebuilt from the raw request_uri with every percent-encoding
decoded except %2F, which stays encoded so it is treated as part of a path
parameter instead of a separator. The encoded slash is then forwarded to the
upstream as is. '.' and '..' segments are still normalized to prevent path
traversal, and a decoded null byte is rejected. The rebuild only runs when an
encoded slash is present, so normal requests keep using the normalized $uri
with no overhead.

Closes apache#11810

Address review feedback on the preserve_encoded_slash option:

- remove_dot_segments: ngx.re.split drops trailing empty fields, which
  turned "/", "//" and paths that resolve to the root into an empty
  string and silently stripped a trailing slash. Rebuild the path with a
  leading "/", merge consecutive slashes like Nginx, and re-add the
  trailing slash only when at least one segment remains.
- access phase: only inspect the path, so an encoded slash in the query
  string no longer triggers a rebuild.
- docs: warn that the option is global and clarify that only real,
  decoded path separators are normalized.
- tests: assert route matching vs route-not-found, upstream forwarding of
  %2F, and cover root, trailing-slash and query-string cases.

… preserve_encoded_slash

preserve_encoded_slash only affects route matching; the request forwarded to
the upstream still uses APISIX's normal (decoded) URI. Remove the inaccurate
'forwarded to the upstream as is' wording and add the Chinese documentation.

Rebuilding the matching URI from the raw request_uri forced us to re-implement
Nginx's whole URI normalization (dot segments, slash merge, NUL, trailing
slash) in Lua, which was the entire safety surface.

Instead, use the already-normalized $uri as an oracle: keep %2F encoded only
when a plain full decode of the request path reproduces $uri exactly (proving
Nginx did nothing beyond decoding). The matching URI is then provably either
$uri or $uri with some '/' shown as %2F. Any request that also needed
normalization (traversal, //, %00, absolute-form, fragment) fails the
equivalence check and falls back to $uri, so no bypass is possible even if the
decode is wrong. The kept slash is normalized to upper-case %2F.

Requests combining %2F with dot segments or consecutive slashes now fall back
to $uri matching (previously matched via the hand-rolled normalization); such
ambiguous requests are handled conservatively. Tests updated accordingly.

…h-route-match

Previously the encoded-slash uri was written into api_ctx.var.uri (and
request_uri) and never restored, so rewrite/access-phase plugins and the
upstream observed the encoded uri instead of the normalized one -- the option
leaked beyond route matching (e.g. proxy-rewrite / uri-based policy plugins).

Now the encoded uri is swapped in only for router dispatch and restored right
after, so plugins and the upstream keep seeing the normalized ctx.var.uri;
only the matched route and its captured params (uri_param_*) retain %2F.

Add a regression test: with the option on, a serverless rewrite hook observes
the normalized uri while uri_param_id still captures the encoded slash.

…cases

- drop the redundant real_request_uri guard (always set for HTTP requests)
- use core.string.find instead of str_find, dropping the extra import
- document the upper-case %2F requirement and the composition with
  delete_uri_tail_slash / normalize_uri_like_servlet (fail-closed fallback)
- add a test asserting the upstream receives the decoded uri