Fix integer/long overflow in content-length parsing, timestamp ordering, and HTTP/2 flow control

[pjfanning]

Silent arithmetic overflow in four places can produce incorrect behavior: bogus content-length acceptance, wrong timestamp ordering, and HTTP/2 flow-control windows that wrap instead of triggering the required protocol errors.

ContentLengthParser — positive-wrapping Long overflow

The result < 0 guard only catches overflow that wraps negative. Values like 1844674407370955163 * 10 wrap to a small positive Long, silently accepting an invalid content-length. Fixed with a pre-multiply bounds check:

// before
result = result * 10 + digit
if (result < 0) fail(...)

// after
if (result > (Long.MaxValue - digit) / 10) fail(...)
result = result * 10 + digit

Timestamp.Ordering.compare — subtraction overflow

math.signum(x.timestampNanos - y.timestampNanos) overflows when comparing timestamps near Long.MIN_VALUE / Long.MAX_VALUE (e.g. the never sentinel). Replaced with java.lang.Long.compare.

HTTP/2 flow-control window overflow (RFC 7540 §6.9.1)

A WINDOW_UPDATE that pushes a window above 2^31 − 1 must be treated as a protocol error — connection error (GOAWAY) at the connection level, stream error (RST_STREAM) at the stream level. Previously both windows were incremented unconditionally with Int arithmetic.

• Added MaxWindowSize = Int.MaxValue constant to Http2Protocol
• updateConnectionLevelWindow now returns Boolean; Http2Demux sends GOAWAY(FLOW_CONTROL_ERROR) on false
• OutStream.increaseWindow now returns Boolean; all four call paths in Http2StreamHandling (Sending, Open, OpenReceivingDataFirst, HalfClosedRemoteWaitingForOutgoingStream) send RST_STREAM(FLOW_CONTROL_ERROR) and transition to Closed on overflow

The overflow check uses a toLong widening cast to avoid the very overflow being detected:

if (outboundWindowLeft.toLong + increment > MaxWindowSize) return false
outboundWindowLeft += increment

[pjfanning]

I think a few of the changes should be non-controversial but the refactor for RFC 7540 §6.9.1 (MaxWindowSize) might be an edge case that we may not want to worry too much about.
2.0 is a good time to add such a change but I'll defer to the consensus about whether to proceed with that change.