Smarter loading for Dask based implementations

[sroet]

As mentioned in #101 , there are some limitations on the DaskContactFrequency, mainly:

• The whole trajectory has to fit into memory as it is loaded once to figure out the length and then for every worker to slice out their trajectory.
• We only support the loading of 1 trajectory file at the moment.

Both these issues should be solvable with a somewhat smart implementation of mdtraj.iterload with a sensible skip and splitting out trajectories.