Split the notifications into DidChange and NeedsRefresh

Previously the same notification was sent for a realm having changes
available for the user to manually refresh, and for the realm being
refreshed and updated with changes. Split these into two different
notifications and better document what exactly they mean.
Rename RLMRealmNeedsRefreshNotification -> RLMRealmRefreshRequiredNotification
Improve the tests
Merge pull request #829 from realm/tg-notifications

Split the notifications into DidChange and RefreshNeeded
Add the name of the class in the missing property value exception

As requested at https://groups.google.com/forum/#!topic/realm-users/e7QAkd6iuA0.
Merge pull request #860 from realm/tg-missing-value-error

Add the name of the class in the missing property value exception
Use std::unique_ptr to hold pointers to C++ types

Cuts down on cleanup code and fixes a memory leak when creating a shared
group throws an exception.
Implement read-only realms

No docs changes because the implementation matches what the docs previously
claimed.

Some assorted design decisions made in the process:

1. refresh and addNotificationBlock are considered "mutating" methods and
disallowed on read-only realms on the grounds that they make no sense.

2. RLMRealm is split into RLMMutableRealm and RLMReadOnlyRealm. This is purely
an implementation detail to slightly simplify the implementation and slightly
improve performance (no checks for the readOnly property). It could be
beneficial to expose this separation in the interface as they do have different
APIs, but I didn't really feel it was worth it.

3. Missing tables in read-only realms are simply treated as if they were empty.
I wanted to make extra columns in tables or missing columns with default values
treated similarly (so that you'd be able to open any realm file that either
matches the schema or can be auto-migrated to the schema), but that'd require
creating separate accessor classes and is far more complexity than it's worth.

4. No attempt is made at handling the case of a read-only RLMRealm in one
process and a mutable RLMRealm in another process sharing a realm file. There's
no easy solution, and more complex solutions (like putting a lock file in /tmp)
should be done in the core and are not very high priority.

5. Realm files must already exist to be openable in read-only mode. Treating a
nonexistent realm as an empty realm is theoretically doable, but would be
awkward (and kinda dumb).
Refactor the implementation a bit

Eliminate the Mutable/ReadOnly subclasses and clean up all the objectstore
stuff.