add Ix.fromSuppliers

[q-ikawa]

This provides simplified constructor for IxSuppliers<T>.

This makes more easier to build Ix<T> from Suppiers<T> , like:

for(Result result: Ix.fromSuppliers( requestA::get , requestB::get, requestC::get )){
  // request*.get() may use many computing resources.
  resultConsumer.accept(result);
}

or Ix.fromSuppliers( requestA::get , requestB::get, requestC::get ).subscribe(resultConsumer::accept);

I know that it can be substituted by Ix.forloop, but I think this makes production codes more simpler or readable in some cases.

[codecov]

Codecov Report

Merging #15 into 1.x will decrease coverage by 0.07%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##              1.x      #15      +/-   ##
==========================================
- Coverage     100%   99.92%   -0.08%     
- Complexity    504      507       +3     
==========================================
  Files         103      104       +1     
  Lines        2526     2548      +22     
  Branches      314      317       +3     
==========================================
+ Hits         2526     2546      +20     
- Misses          0        1       +1     
- Partials        0        1       +1

Impacted Files	Coverage Δ	Complexity Δ
src/main/java/ix/IxFromSuppliers.java	100% <100%> (ø)	2 <2> (?)
src/main/java/ix/Ix.java	99.42% <50%> (-0.58%)	231 <1> (+1)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update add721b...fd0028a. Read the comment docs.

[akarnokd]

Thanks, but this pattern is quite unusual for IxJava (and RxJava) and can be emulated via various ways, such as:

Ix.<IxSupplier<T>>fromArray(requestA::get , requestB::get, requestC::get).map(IxSupplier::get).