FR: opt-in strict=False-style leniency for control chars in strings (default behavior unchanged)

**TL;DR:** opt-in flag to accept unescaped control chars (e.g. a bare newline)
inside strings, mirroring stdlib `json`'s `strict=` — default behavior and
spec-compliance untouched. I'll write it; just want a 👍/👎 before I sink
time in. No reply needed either way: a 👍, or silence past ~2 weeks, I'll
take as a green light to send a small draft PR (`loads()` only,
`strict=True` default) for you to review whenever's convenient. An explicit
comment is a stop sign. Feel free to just close this if it's not wanted.

**Why:** `pyjson5.loads('"foo\nbar"')` (a literal newline byte, not the
two-char `\n` escape) raises `Json5EOF`. I know 1.4.7 made this rejection
deliberate, "per spec" — not disputing that default. My case: real files
from a shipping system whose own runtime parses them as-is, bare newlines
included — not malformed/legacy data, just not spec-pure JSON5.

**Why this stays out of your compliance/correctness/security bar:**
- Default unchanged — new kwarg defaults to today's strict behavior, so the
"all valid JSON5/JSON can be read" guarantee is untouched.
- Decode-only — `encode_*()` and its HTML-safety escaping are untouched.
- Documented as an explicit spec deviation when enabled, same caveat stdlib
`json` gives for its `strict` flag.
- Precedent: the pure-Python `json5` package (dpranke's, on PyPI as
`json5`) already has this exact `strict` kwarg/semantics — matching an
existing convention, not inventing one.

Start by locating the loads() entry point and the parser logic that rejects bare control characters; compare the requested behavior with Python's stdlib json strict= semantics. Done means an opt-in strict=False path accepts those characters while strict=True remains the default and encoding behavior is unchanged.

Written by the indexing model from the issue text.