Wrapper classes

Storing our own data on Outlook objects is a dubious practice. Although Outlook allows us to do this through UserProperties, and version 3 does so, there are a number of problems with this:

1. UserProperties are not thread safe;
2. When a UserProperty is changed, Outlook sends an ItemChange event which, in version 3's multi-threaded design, ends up being handled in a different thread. This can easily lead to a cascade of ItemChange events.

Consequently, it's better not to store our own state data on the outlook item directly. We need a wrapper class on a one-to-one basis with Outlook items, and, indeed, version 3 provides this in the form of SyncState classes. the 3.0.11-develop branch provides a single factory/repository object for these wrappers, which greatly speeds up access to them and prevents threading issues creating duplicate instances.

My understanding of the development of the code is that SyncState objects were originally intended only to hold the state/transition engine state, and that additional functionality accreted to them over time. But the hybrid strategy with some information held on user properties and some in the SyncState is a bad compromise. Storing information on UserProperties doesn't really work in a multi-threaded design.

Consequently I believe we need to upgrade our SyncState classes into first class Wrapper classes, which will be our only access to the underlying Outlook item, and cease using UserProperties altogether.