support "unlimited" for the Jackson stream-read constraints

[pjfanning]

Motivation

Review on #3515 preferred an explicit unlimited keyword over -1 as a magic number.
Auditing the configuration listed in #3513 for other -1-means-unlimited settings turned
up exactly one family: the Jackson stream-read constraints read.max-document-length and
read.max-token-count, whose comments say "-1 means unlimited" but which only accept
numbers (getLong).

Nothing else in that list qualifies: the other new settings are durations, counts with
real defaults, booleans or strings, and fork-join-executor.minimum-runnable = -1 means
"JDK-aware default" — not unlimited — so the keyword would be wrong there.
compression.max-decompressed-size already gains unlimited in #3515.

Modification

JacksonObjectMapperProvider in both serialization-jackson and
serialization-jackson3 reads unlimited as -1 for read.max-document-length and
read.max-token-count, and the reference.conf defaults are written as unlimited. A
negative number such as -1 is still accepted, so existing overrides keep working.

Both modules are changed together so the jackson3 section keeps mirroring the jackson
one, per the migration guide.

Result

max-document-length = unlimited and max-token-count = unlimited work in both
modules; the effective defaults are unchanged.

Tests

• New support unlimited as a StreamReadConstraints value test in each module's
  JacksonFactorySpec, asserting the built StreamReadConstraints carries -1
• The existing suites also now exercise the keyword through the changed defaults
• sbt "serialization-jackson/testOnly org.apache.pekko.serialization.jackson.*" — 129 passed
• sbt "serialization-jackson3/testOnly org.apache.pekko.serialization.jackson3.*" — 127 passed
• sbt "serialization-jackson/scalafmtCheckAll" "serialization-jackson3/scalafmtCheckAll" — clean
• MiMa left to the Check / Binary Compatibility job; the only code change is a private
  helper

References

Refs #3513, Refs #3515