Normalize capture times

This is a tricky problem and it's introducing little gaps in the sequences. It's not a super big blocking issue, but it is annoying.

See also https://github.com/mapillary/mapillary_tools/issues/145, as this is caused by the cameras, not by the script, meaning that the mapillary script is affected by this too.

Here's a brain dump of what I'm struggling with.

---

Given a camera that is configured to capture images every 1 second:

* There are several exif tags in the images that you can inspect in order to know when the image was taken. `DateTimeOriginal`, `DateTimeDigitized`, and `GPSDateTime`

* `DateTimeOriginal` and `DateTimeDigitized` can drift based on how long it takes to write the image buffer to storage. So there may be gaps in the images, or there might be 2 images with the same `DateTimeOriginal`

* All of these tags only have second-precision, as does the filesystem iteslf. Some cameras (not the Sony ones) do write additional exif tags with subsecond-precision timestamps, but that's new and nonstandard.

* When a camera doesn't have GPS, it is using an internal clock which can drift away from true GPS time.

* When the cameras have GPS, I would expect `GPSDateTime` to be very accurate, however I sometimes see contiguous images with an identical `GPSDateTime`. (maybe because of 1 second precision and rounding?)

```
Bryans-MBP:101MSDCF bryan$ exiftool -s -n -GPSDateTime -DateTimeOriginal DSC07780.JPG
GPSDateTime : 2016:09:03 16:49:32Z
DateTimeOriginal : 2016:09:03 11:49:32
Bryans-MBP:101MSDCF bryan$ exiftool -s -n -GPSDateTime -DateTimeOriginal DSC07781.JPG
GPSDateTime : 2016:09:03 16:49:34Z
DateTimeOriginal : 2016:09:03 11:49:33
Bryans-MBP:101MSDCF bryan$ exiftool -s -n -GPSDateTime -DateTimeOriginal DSC07782.JPG
GPSDateTime : 2016:09:03 16:49:34Z
DateTimeOriginal : 2016:09:03 11:49:34
```

* So what happens when 2 images occupy the same time?
```
1472921372000: left/DSC07662.JPG 39.9 right/DSC04244.JPG 40.4 back/DSC07780.JPG 40.5 front/DSC08975.JPG 40.7
1472921373000: left/DSC07663.JPG 41.2 right/DSC04245.JPG 42.0 front/DSC08976.JPG 41.5
1472921374000: left/DSC07664.JPG 42.1 right/DSC04246.JPG 42.0 back/DSC07782.JPG 41.7 front/DSC08977.JPG 40.6
```
See that `back/DSC07781.JPG` got dropped - it shares time 1472921374000 with `DSC07782.JPG`.

* You can sort of use the filename to infer the sequence. But the `DSCxxxxx` naming convention is arbitrary (e.g. different vendors make up their own system), and even loops back around to `DSC00000` sometimes.

* Timezones are annoying. `GPSDateTime` is in UTC, `DateTimeOriginal` is in local camera time (for example PST), and JavaScript assumes times are local to the computer running the script (in this case EST), unless you tell it otherwise. (This is the reason for the weird start/end times reported in streetcar-info output).

---

So the best way forward seems to be:

- [ ] adjust the scripts to allow for multiple images per time,
- [ ] then when running through a sequence, when a duplicate is detected, allow an image to be slotted into an earlier or later empty timeslot, using any of the 3 time exif tags w fallback to using the filename for guidance.

Start by tracing the scripts that sequence images and the streetcar-info output mentioned in the issue. Define how duplicate timestamps should be retained, how earlier or later empty slots are selected, how the three EXIF timestamps and filename fallback are prioritized, and how timezone handling is made consistent. Done means sequences no longer drop images that share a timestamp and reported start/end times are correct.

Written by the indexing model from the issue text.