feat: epmap_collect

[oameye]

At the moment it is just a copy of epmap with a result dictionary catching the results. I think this can be annoying for maintenance. So probably, we should make a kwarg in epmap_map that optionally saves the results in the dictionary. That way, we have more code reuse.

resolves #120

[samtkaplan]

I agree, the duplicate code here doesn't seem quite right. Should we worry about type stability here (maybe we shouldn't since there is not really any performance critical code here)? That is, if it is controlled by a kwarg, then the return-type of epmap will depend on the value of that kwarg.

[oameye]

I don't think type stability would matter as epmap_map still has the same output. It would be a kwarg that mutates the result dictionary or not.

[oameye]

Could you run CI to see if the tests pass. Locally it ran fine, but it would like to know if there are any problems with CI

[samtkaplan]

Presently, the epmap returns journal and eloop.task_pool_timed_out here. I was thinking that this would be changed to now return either journal,eloop.task_pool_timed_out or journal,eloop.task_pool_timed_out,results depending on the kwarg. But sounds like you have something else in mind? Were you thinking to change what is returned to a single dictionary? I think that would be fine. It would be a breaking change, but might be worth it.