some minor refactoring; flash_finder as a method of Experiment

[vineetbansal]

Refactoring

[vineetbansal]

This is ready to merge after you've had a chance to review. We went through the first commit together. In the second commit:

• Since what we're essentially doing is taking information from frameData.txt (our Timing class) and other-frameSynchronous.txt (our FrameSynchronous class) and merging all the information together, the place it really belongs to is in the Timing class. This happens now through a merge_sync method. Since it runs really fast, its results are returned to the caller (and the .timing information not modified in that class).
• Since the information from frameDetails.txt dictates what the frame indices and timings are, and the information from other-frameSynchronous.txt is merged into it by looping over the rows of the former, the natural place for this is in the Timing class where we do a left merge of the dataframes (analogous to a left join in a database).
• The Experiment class caches the results of this method in its .timing_dataframe attribute (initialized in the constructor since it is fast to compute).
• Most of the smoothing and other logic is the same as before, except that we're not doing the initialization to -1000 or -10 of certain attributes. After going through the code carefully, I realized that doing things that way gives you worse values (since these -1000 etc. have no real bearing on the true values obtained from these devices) than just keeping values as np.nan. (where we're explicitly saying we don't know the relevant values).
• I've verified that all values match up with the legacy code, except in some corner cases where our code is more "correct" than the old one. As an example, the other-frameSynchronous.txt having none, or multiple values for a particular frame index (which it does in our sample data), causes an Exception which is simply passed. In general its a very bad idea to catch Exception and continue as if nothing happened.
• I've removed some code that was added to the FrameSynchronous class which is never used.
• I'm returning the data that is written to hiResData.mat as a return value of flash_finder(). The caller can ignore it if they don't want it, but this will help in writing better unit tests in the future, where we can inspect these values.
• The overall time for our /bs data has gone from 9 seconds to almost instantaneous (0.01 seconds).
• Other comments inline with the PR.