Travel Path Routines

[wrightky]

Introduces two main updates:

• Adds a new routine, snake_plots(), which lets you visualize particle travel with the previous locations shown as a fading tail. It's named after the game snake, as it's a pretty close visual analog. This makes use of the efficient LineCollection class in matplotlib to plot lots of lines at once, so the routine is quick for even large numbers of particles. It's built to be pretty flexible, so it should be useful for lots of cool plots: users can control (1) the length of the tail, (2) the interval between successive points, which smooths out the travel path if you're not showing every step, (3) the start and end colors of the snakes, which by default is a light orange that fades from alpha=1 to 0.

• Updates the draw_travel_path() routine to make use of the LineCollection, as the old version could be very slow and crash for large numbers of particles. The new version is very rapid. I've also introduced a similar interval parameter to skip over iterations and smooth out the paths. Lastly, because the legend can be a mess if people specify a lot of particles, it defaults to not showing one, with an optional input boolean plot_legend, to turn it on. Other changes are just aesthetic, like adding shadows behind lines to help their visibility, and overall just reducing the amount of information shown to focus on the paths.

Lastly, updated the examples and associated docs for the travel path routine. Also fixed a bug I ran into in get_state() if some particles don't iterate very far if originally routed by time.

We can wait to merge this until after the review process, although most of these things are periphery changes, so it might not matter. Up to you

[elbeejay]

Before we merge, I think you should update the version number in __init__.py to either "2.1.0" or "2.0.1" because merging this PR will create a difference between the pip version and the repository version of the code. I think this is in-line with PEP-440, which outlines Python software versioning "three components ('major.minor.micro')". I don't know whether we should consider this "minor" or "micro" in scope, but it should definitely change the version number so that we can do another "release" on GitHub which updates the pip version.

Besides that, I think we're good to merge.

[wrightky]

Good point on the version number, I'll make sure to keep proper versioning in mind for future updates. Looked into it and it seems like this classifies as 'minor', so I've updated to 2.1.0.