Avoid deadlock consuming from blocking Iterator

[Scottmitch]

Motivation:
The blocking streaming APIs allow for specifying a Iterator
as input which is consumed by ServiceTalk. ServiceTalk assumes
it can consume in batches from the same thread in order to make
progress. However if the Iterator next() method is dependent
on external input we may deadlock:

• PublisherAsBlockingIterable.onSubscribe(..) does a request(16)
• FromIterablePublisher.request(..) loops calling hasNext() and
  next() until demand is exhausted. Each loop iteration calls
  subscriber.onNext(next()).
• The same thread looping in FromIterablePublisher.request(..) is
  also responsible for draining the queue in PublisherAsBlockingIterable.
  This means that no data will be sent downstream until
  FromIterablePublisher exits the loop. This maybe perceived as
  “dead lock” because no data is sent even if the Iterable provides an
  element.

Modifications:

• FromIterablePublisher and FromBlockingIterablePublisher check to
  unwrap from PublisherAsBlockingIterable if possible to directly
  access the underlying Publisher. This skips thee consumption
  via thee Iterable API and avoids the dead lock loop.

Result:
No more dead lock when using HTTP / gRPC API conversions and providing
Iterable that is dependent upon external events to make progress.

[Scottmitch]

followup investigation required: #2205, however I would like to unblock the immediate concern.