Collections item key doesn't start with 0

[manycoding]

start=0 is set as default for Cloud Items puller, however collections have custom indexes, 0 not necessary the first.
Maybe the jobs too.

[manycoding]

This bug raises one question:
is start in Arche needs to be mirrored as our API or not?
Currently, for jobs:

1. _key repeats index, e.g. 112358/13/21/10 is always 10th element in a job
2. Thus, start specifies what number of elements to skip
   Collections:
3. _key is arbitrary, e.g. 10 or 324vds53, it could be or could be not related to an index
4. Thus, to correctly specify start one needs to know the _key of nth element

So, do we want to user to specify and find out start himself, like:

Arche(start="112358/13/21/100")
Arche(start="asfd32rfas")```
Or better to keep the current way of implying that start is nth element after start.
`Arche(start="100")`

[nerevaryn]

I think in the case of a normal ordering, we can use the current approach because it doesn't change anything. For the jobs/collections where we have not direct order of items/keys then a person should choose exactly the item number which to start from (not an amount of items to be skipped), because when a user puts something as a value to "start" it means he/she knows where exactly to start from, when to count amount of items before this item to start will be much more difficult task

[manycoding]

The current approach doesn't support start for collections.
So I am asking it either 1 or 2 in this library.

[manycoding]

So the idea is when somebody specifies start, he means item key and he knows it.
Thus, there should be separation between start and start_index.
On top level, everything will be the same, i.e. start will mean item key.