Undocumented duplicate key behaviour for events and rules

## Describe the bug

High level description of the issue is we can create duplicate keys in our rules and the library will only use the last duplicate in the rule

For example if this is my rule:
```
{
"source": ["aws.s3"],
"source": ["aws.sns"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["s3.amazonaws.com"],
"eventSource": ["sns.amazonaws.com"]
}
}
```

A customer may expect it to capture both detail S3 and SNS events from CloudTrail. But it turns out we only trigger only the second key (which in this case is SNS).

This is within the bounds of the JSON spec https://datatracker.ietf.org/doc/html/rfc8259#section-4
> When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only.

Still, it's better if we 1/ handle it for users when de-serializing via ObjectMapper[1] and 2/ document this edge case if they are passing the JSONNode to us.

[1] https://github.com/FasterXML/jackson-databind/issues/237 shows that we can use `DeserializationFeature.FAIL_ON_READING_DUP_TREE_KEY`

Start by reviewing duplicate-key deserialization through ObjectMapper and the JSONNode input path, then read the linked Jackson FAIL_ON_READING_DUP_TREE_KEY reference. Done means the duplicate-key behavior is handled for ObjectMapper users and the JSONNode edge case is documented, with the observed last-key behavior verified.

Written by the indexing model from the issue text.