Add top-level combine<Iterables|Lists|Maps>

[matanlurey]

Let's start with just discussing combineList, which is currently implemented in various forms internally, and has lots of utility and potential perf-saving.

//// Returns a new list that represents [lists] flattened into a single list.
///
/// All methods and accessors treat the new list as-if it were a single concatenated list,
/// but the underlying implementation delegates to each corresponding list as necessary. 
List<T> combineLists<T>(List<List<T>> lists) => ...

Here is an example of implementing first:

class _CombinedList<T> implements List<T> {
  final List<T> _lists;

  T get first {
    for (final list in _lists) {
     if (list.isNotEmpty) {
       return list.first; 
     }
    }
   throw ...
  }
}

/cc @nex3, @leonsenft, @ferhatb

FWIW I believe @isoos originally implemented something like this for the high-performance table, and it worked really well. I'd also eventually like to see the same thing for Map and Iterable if possible - though to simplify things they may need to be read-only, but worth discussing anyway.

[nex3]

I could see a CombinedListView class for this. Does this mean that [] would be O(n) for the number of lists that were combined? Or would you track some sort of radix list?

[matanlurey]

I could see a CombinedListView class for this. Does this mean that [] would be O(n) for the number of lists that were combined? Or would you track some sort of radix list?

I think given that I imagine this is usually just 2 or 3 lists, I'd probably implement as a O(n) where n is the number of lists that were combined. That's how it is implemented today and is definitely just a few lines of code.

[nex3]

That sounds fine to me.

[isoos]

I don't think O(number of lists|maps combined) is a big issue. When people want to combine 1000s of lists or maps, they will probably figure out better data structures to represent what they need anyway.