mod_substitute: enforce max line length on unmatched tail

[mcc0nnell]

SubstituteMaxLineLength is intended to cap the resulting line length, but successful substitutions do not consistently account for the unmatched tail after the final match.

On current trunk (118b84ae18a59ff1e3b99cd1da28da2d0c0c180c), with SubstituteMaxLineLength 10, a 10-byte line where an early match expands by one byte can produce an 11-byte response instead of returning APR_ENOMEM.

Before this change, the following all exceeded the configured limit:

• regex, flatten mode: HTTP 200 / 11-byte body
• regex, quick (q) mode: HTTP 200 / 11-byte body
• literal (n), flatten mode: HTTP 200 / 11-byte body

The literal quick path already rejected the same case because it separately checks the remaining bucket length.

This change accounts for the final unmatched tail in the two flatten paths and in the regex quick path.

Validation against a current-trunk build with mod_substitute enabled:

• 10-byte input -> 11-byte result: rejected in regex f, regex q, literal nf, and literal nq
• 9-byte input -> exactly 10-byte result: accepted in all four modes
• git diff --check: clean

This is a SubstituteMaxLineLength enforcement / memory-limit hardening fix. I have not demonstrated memory corruption, an out-of-bounds access, or another exploit primitive.