Generalize data access functions

[dmpetrov]

[Based on several discussions with @volkfox & @skshetry]

collect()/collect_one() needs to be combined - return single-value-list when only one signal is requested
iterate()/iterate_one() - the same

[rlamy]

BTW, I'm not sure why we have both iterate() and collect(), since it's trivial and common to turn an iterator into a list (see e.g. usage patterns for built-in map()). It also leads users to inefficient code like for x in chain.collect():.
My suggestion: remove collect() and rename iterate() to collect().

[skshetry]

So, it looks like we'll have two APIs: collect() and collect_flatten().

[skshetry]

But we need to decide what to do with results() and to_records(). They are very similar to collect_flatten.

[dmpetrov]

if results() == collect_flatten() then, yes, let's rename it to collect_flatten.

to_records() does not look similar since it returns json of flatten fields. I'm not sure this is needed in user API level / DC. We can keep in DatasetQuery level just in case or even rename it to _to_records.

[dmpetrov]

hey folks, does anyone working on this? This is P1 - we need it ASAP. Like till Monday morning.

[dmpetrov]

@ilongin are you working on it?