prospective parachains API chain: Provide N candidates

[eskimor]

Don't only provide one candidate, but N, where N is given in the message. Implementation: simple replacement of next() with take(N).

[alindima]

I think it's more complicated than a simple replacement with take(N). The current implementation always takes the first available node.
For multiple candidates, we need to return a chain of valid candidates, of the requested size. So we need to do a depth-first search through the tree. If we can't find a chain of N candidates, we should return the chain of the maximum size we could find instead. Any exhaustive search would work but I think dept-first is more suited because we can be optimistic that collators are cooperating and there's only one valid option (and therefore complexity would be O(N) usually)

[eskimor]

Err on what is the cheapest for the validators in the worst case (non cooperating collators). We don't have to find an optimal solution, if the parachain is producing forks.

[alindima]

I guess it's no harm in accepting some amount of forks coming from collators. After all, if that weren't the case, the entire fragment trees concept could have been replaced with fragment "chains".
I implemented a depth-first search as part of my PR, but it's bounded by the requested candidate count (which shouldn't be more than two or three). So I think it's a decent solution, which would still permit having forks in the parachains, let me know your thoughts