feat: NotificationManager should accept a flag for whether a change to local vs remote state results in the notification

[runspired]

now that SchemaRecord only shows remote state by-default, updates generated by changes to local-state are unnecessary.

additionally: updates resulting from application of local state become necessary where before they were unnecessary (this is essentially a bug in the SchemaRecord world).

having separate channels will enable better performance tuning

[runspired]

While working on a demo app, @gitKrystan discovered that the following scenario fails due to the current cache implementation and lack of channeling here.

• checkout a PolarisMode record for editing
• make edits to the record
• save the record using the updateRecord op code (probably reproduces without this)
• API reflects the new state back in its response

The API response fails to notify the immutable record the value has changed. This is because the comparison guarding the notification compares the local-state to the new state and decides no notification is needed.

• during the initial edit, both the Mutable and Immutable record are notified of the change
  • only the Mutable record updates the value because the remote value has not yet changed
• when the API response is received, the local value and new remote value are compared, no change is seen so no notification is emitted.

At a minimum, we need to change the cache so that in PolarisMode we are comparing former remote to former remote, but channeling would also help here because we could notify only the local channel for the initial edit, the remote channel for the server response, and only notify the local channel again if the api response differs from the local state.