Proposal for notes

@cheddar -- thoughts?
It seems like it will result in attempting to maintain state in two places (i.e. note must exist and `hasNote` must be set to true), meaning that a "correct" implementation of any feature will not be able to rely on `hasNote` alone as a bug or race or error of some sort might result in a note being created and `hasNote` not being set.

I understand the want to indicate that a note exists without loading up the message immediately, but I also wonder about issues with maintaining this state.  We can do it on the API end and minimize potential races, but it still seems like we are implementing it in two places.

I guess the question is, which is worse

1. Having to load up the notes for a given time period in order to know if a datum has a note associated with it, happens 100% of the time
2. Not displaying a note associated with a datum because of state mismatch, happens some small percentage of times when there is a race or other failure condition

If you feel that (1) is worse, then we should have the field.  I will suggest that the field should be the id or array of ids of the threads associated with this datum, however.