Access conditions reused the URL Rewrite trigger matcher, but the two want
opposite defaults. A rewrite trigger decides whether to apply a transformation,
so leaning towards firing is harmless; an access condition decides whether to
let a request through, so it has to lean the other way.

Borrowing that matcher meant a policy could not express the rule the customer
actually needs, and three ways to get more access than the policy granted:

  - "parameter must be absent" was inexpressible. Reverse was only evaluated
    when the parameter was present, so a public policy written with it also
    rejected the legitimate bare request.
  - matchers were counted per matching value rather than per configured name,
    so repeating one parameter satisfied a rule that required a different one.
  - only one supplied value had to match, so an extra value on a repeated
    parameter went unchecked.
  - an uncompilable reversed pattern granted access instead of denying it.

Evaluate conditions in a dedicated evaluator instead, with absence
expressible, every supplied value checked, matchers counted per name, and
anything unevaluable denied. mw_url_rewrite.go is left alone so existing
rewrite triggers are unaffected. Evaluation no longer records matches in the
request context data either, so it cannot disturb the trigger numbering a
later URL Rewrite relies on.

The same fixes apply to the header, path part, session meta and request
context matchers, which shared the defects.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>