Prevent content from steering the string match filters

[FreeAndNil]

Three findings, one commit: all three sit in StringMatchFilter, whose Decide
was a near-duplicate of PropertyFilter.Decide, so each defect existed at two
sites. Both now share one implementation, which is also why MdcFilter and
NdcFilter need no change.

• f018 The substring search was culture sensitive, and a linguistic search
  skips ignorable characters, so content holding a NUL, a soft hyphen or a
  zero-width space between the letters of stringToMatch still matched it, and
  the decision varied with the host culture. Ordinal now, so the filter decides
  the same way a reader of the log would.
• f017 An abandoned regex match was treated as a non-match. But the content
  decides whether the deadline is reached, so in an AcceptOnMatch allowlist
  ending in a DenyAllFilter, content could suppress its own record. The new
  timeoutDecision decides those events, still Neutral by default; Accept
  makes such a chain fail towards logging.
• f041 The default matchTimeoutMillis drops from 1000 to 50. The match runs
  under the appender lock, so the deadline bounds what one crafted event costs
  every other logging thread. A legitimate match takes a fraction of that.

filters.adoc documented the old deadline and outcome, and its example set the
value back to 1000; both corrected, and timeoutDecision is documented against
the allowlist arrangement the same page recommends.

Deliberate default change: f041. An operator whose pattern genuinely needs
longer must now set matchTimeoutMillis, and gets the existing once-per-filter
warning if a match is abandoned.

Tests: 13 new across both filters, and each fix was checked by reverting it and
confirming the right tests fail (5 for f018, 3 for f017, 1 for f041).