Filters change events and only relays major changes.

This asks the same question as org.jabref.logic.undo.CoalescingPolicy — is this change the continuation of a run of typing? — for a different consumer, and the two answers are not interchangeable. The policy decides how much one Ctrl+Z takes back, where being wrong costs a keystroke either way. Here a change marked filtered arms no backup and is held back from the shared database until the next major change (see org.jabref.logic.shared.DBMSSynchronizer), so filtering too eagerly delays what other clients see, while filtering too little only writes a backup more often. That is why this stays with the conservative rule below — a change to another field or entry, or more than one character at once, is major — instead of the policy's contiguity and word rules.

The charactersChangedCount test is a guess at what the caller now says outright: a keystroke records as org.jabref.logic.undo.EditSource#TYPING, everything else as a command. Should the two granularities ever have to agree, that source is the thing to carry into the event, rather than either side re-deriving it.