docs: add an "On performance" section to the design page

[declaresub]

Records the reasoning behind prioritising correctness over speed, so it lives in the docs rather than only in discussion.

• Header vulnerabilities (smuggling, response splitting, injection) come from parsers disagreeing, not from slow code — hence driving every header from its RFC ABNF, where the grammar is the specification.
• Notes the direction that's easy to overlook: response splitting usually originates on the build side, which is why validity is a property of the field types rather than a check inside parse().
• States plainly what is not claimed: no benchmarks, throughput unmeasured. If it ever matters, the useful measurement is worst-case behaviour on hostile input (super-linear backtracking → algorithmic DoS), which is why parse() bounds input length via Header.max_length first.

Claims checked against the source; docs build clean with -W.

🤖 Generated with Claude Code