Document what to do with duplicate items

I can probably work out what to do by checking the code, but it would be good for this to be defined as part of the format. An example is for the review on fd4109dbd9e1, this has reviews stored under note e81a4e0ea017 and CI status under note 4914d5adea78. Using `git show` to view the notes directly gives
##### Review

```
> git show e81a4e0ea017
{"timestamp":"1450125974","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}
{"timestamp":"1450215328","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}
{"timestamp":"1450219553","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}
{"timestamp":"1450222101","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}
{"timestamp":"1450338870","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}
{"timestamp":"1450338936","targetRef":"refs/heads/master","reviewRef":"refs/pull/5/head","requester":"stp-ip","description":"Fix typo in README"}

{"timestamp":"1450338936","reviewRef":"refs/pull/5/head","targetRef":"refs/heads/master","requester":"stp-ip","description":"Fix typo in README","baseCommit":"6302bf385c36958fb8881e43f11daeeb4ed42cc0"}
```

For this I assume just taking the latest instance would be appropriate.

> Although how to determine latest? Judging by the duplicates on the last two entries `timestamp` is not guaranteed to be monotonically increasing, and even if it were on a single machine then what happens with edits to the same review from multiple machines?
##### CI Status

```
> git show 4914d5adea78
{"timestamp":"1450504163","v":0,"agent":"Jenkins(1.627) GitNotesJobLogger","url":"https://jenkins-dot-developer-tools-bundle.appspot.com/job/git-appraise/118/"}

{"timestamp":"1450504169","v":0,"agent":"Jenkins(1.627) GitNotesJobLogger","url":"https://jenkins-dot-developer-tools-bundle.appspot.com/job/git-appraise/118/","status":"success"}

{"timestamp":"1450219554","status":"success","agent":"cla/google"}

{"timestamp":"1450126113","url":"https://travis-ci.org/google/git-appraise/builds/96828980","status":"success","agent":"continuous-integration/travis-ci/pr"}

{"timestamp":"1450126043","url":"https://travis-ci.org/google/git-appraise/builds/96828980","agent":"continuous-integration/travis-ci/pr"}

{"timestamp":"1450125975","url":"https://travis-ci.org/google/git-appraise/builds/96828980","agent":"continuous-integration/travis-ci/pr"}
```

Since there are multiple agents submitting their CI status I guess the latest entry from each unique `url` (or `agent` when `url` is missing?) value may be appropriate.

> Here you can actually see that different machines have different timestamps. In this case it doesn't really matter as each agent is on a unique machine so that when partitioned by `url` or `agent` the `timestamp` is at least increasing, even if not guaranteed to be monotonic. But I can imagine some form of CI agent that involves passing the job through multiple machines as it works, which could result in non-increasing timestamps for a single job.

 

> It might be worth adding a required third-party `id` entry to allow agents without a `url` (like `cla/google`) to add multiple statuses and update them?

 

> Also just noticed that it appears the travis-ci implementation is actually prepending its new statuses as it works rather than appending like the rest seem to.

These are the only parts of the spec that I've really looked into so far. A quick glance at robot comments seems like it should be ok since there's nothing there to update, I'll take a deeper look at review comments and add an update.