update Counter and AutomergeText so that they only register change signals IF the content they point to changes

[heckj]

With #150, AutomergeText and Counter (as ObservableObjects) reflect a signal that "something's changed" when ANY change happens to a document. Perhaps with #148 in place, update that process (and assocaited tests) so that the their "objectWillChange" signals are only triggered when the content they point to has changed.

The easiest cut would be to add additional tracking in AutomergeText to hold a "current value hash" and compare when the Doc.objectWillChange() comes in, potentially reflecting updated content in the Automerge document.

A more optimal solution would be to leverage the diff API (#148) and have the instances watch for only changes of their objId, which would potentially mean a different Combine published exposed that provides more granular data than objectWillChange(), ideally with information about what changes parsed from the patches returned by the diff API.

There's variations on this that might include instances of AutomergeText and Counter registering a callback function that a Document could be responsible for triggering, which would move the logic for this filtering and triggering from AutomergeText and Counter into Document itself, which could be notably more efficient in the scenario of lots of these instances, a deep document, and sparse change updates via merge, sync, etc.