fix: do not let gather request more upstream items than its downstream demand

[jnbdz]

MultiGather.request() forwards one upstream.request(1) for every downstream request() call, in addition to the request(1) issued after each emitted item. When the downstream replenishes its demand from inside onItem (which bounded-buffer adapters such as the Vert.x bindings' ReadStreamSubscriber do every time their buffer drops below half), each of those calls adds a credit at the source that nobody consumes. With a Multi<Buffer> piped into a Vert.x HttpClientRequest the surplus reaches ~11,000 credits per 100,000 items. As soon as the downstream pauses, the source keeps serving the surplus and onItem forwards every extracted item without looking at the demand, so the paused subscriber buffers tens of thousands of items and the application runs out of memory. This is the root cause of quarkusio/quarkus#53099.

This PR makes the operator request a single upstream item at a time, and only after reserving a unit of downstream demand for it:

• requestNextUpstreamItem() skips when a request is already in flight, otherwise takes one unit from demand (left untouched at Long.MAX_VALUE) and requests one item;
• when an upstream item does not produce an extraction, the reserved unit carries over and the next item is requested directly;
• unused reservations are given back to demand on upstream completion so drainRemainingElements() sees the right count.

MultiGatherTest#requestsIssuedWhileDeliveringAnItemMustNotOverRequestUpstream drives the operator with an emitter served one item at a time and a subscriber that replenishes a 16-item buffer from onNext; before the fix the operator requests ~11% more items than the downstream did and delivers ~1,100 items after the subscriber stopped requesting.

Verified with the reporter's Quarkus reproducer: with the current operator it runs out of a 1 GB heap within seconds, with this patch it streams for a minute with the source requested count equal to the item count. The MultiGatherTckTest and the full implementation suite (12,255 tests) pass.

[jponge]

Thanks.

• demand can go negative at completion. requestNextUpstreamItem() now CAS-decrements demand even after onCompletion() has already run and drained against it, leaving demand negative and reserved permanently
  stranded. The original code called upstream.request(1L) unconditionally, a harmless no-op on a completed source, but the new path modifies demand, which is unsafe post-completion.

• Non-atomic guard on reserved. reserved.get() > 0 and reserved.incrementAndGet() are not atomic. Two concurrent callers can both pass the guard and issue upstream.request(1L). Use reserved.compareAndSet(0L, 1L) as
  the gate instead.

Also missing: tests for the no-extraction accumulation path and for the onCompletion demand restoration.