Fix Shooting Point Analysis - #725

Quick side note @hejung (not specific to the code; review will come later): It looks like you don't have matching email addresses in you git config and GitHub account. This is either because your git config doesn't have an email set, or because the email you set isn't linked to GitHub. See more:

• https://help.github.com/articles/setting-your-commit-email-address-in-git/
• https://help.github.com/articles/setting-your-commit-email-address-on-github/

Setting this helps us track contributions, and ensures that you get credit for your contributions!

What is the status on this? Can this be merged?

@jhprinz : Our policy was to hold off on user contributions until the paper is accepted. This will be one of the first PRs to be merged once we accept external contributions!

Please note that we have changed to the OPS license from LGPL (2.1 or later) to MIT. For any pull request to OPS that was started while the license was still LGPL, I need an explicit confirmation that you approve of the license change. Please add a comment with something like "The changes in this pull request are licensed under the MIT license."

The changes in this pull request are licensed under the MIT license.

Now rebased on the current master.

Just as a reminder what changed:
ShootingPointAnalysis.keys(), ShootingPointAnalysis.items() and iterating over the ShootingPointAnalysis now hide that we in fact that we use the string representation of the snapshots coordinates instead of the snapshot as key.
I.e. we now return the snapshots associated with the hashstring whenever we are asked for a key, the strings are only accessible via the keys of the self.hash_representative or self.store dictionaries.

This technically changes tested behavior, but I'm of the opinion that the tested behavior was incorrect from a user perspective, hence a bug. (This is the difference between API breaking and not.)

Just to check that no one is relying on the old behavior (that keys in shooting point analysis results are internally string reps of the coords, not the snapshots), mentioning @sroet @arjunwadhawan -- if either of you have a good reason to be concerned about this PR, let me know. If not, I'll doubt that it has become important to anyone's workflow. I leave this open for comment for 48 hours, merging no earlier than Wednesday, 26 Feb.

This also opens the way to something else I was thinking about: since this hides the actual keys from users, they can be different for different engines. The UUID of the statics object in snapshots from OpenMM can be used, instead of the coordinates. I think this might make the analysis faster (might be able to only load UUIDs, not the whole snapshot).

@dwhswenson I don't think this should raise any issues on my codes, and I agree that the current tested behavior is incorrect. So if it raises issues on my code I should be able to alter it pretty quickly.

No complaints, so merging it!