The page index needs to be per-person in group libraries, and it should
still work in read-only libraries, so it doesn't make sense to store it
on the item. This uses a synced setting in the user's library instead.
```
var noteContents = item.note; // was item.getNote()
var schemaVersion = item.noteSchemaVersion;
item.setNote(contents) // default to Zotero.Notes.schemaVersion
item.setNote(contents, schemaVersion) - explicit version
```
This lays the groundwork for moving collections and searches to the
trash instead of deleting them outright. We're not doing that yet, so
the `deleted` property will never be set (except for items), but this
will allow clients from this point forward to sync collections and
searches with that property for when it's used in the future. For now,
such objects will just be hidden from the collections pane as if they
had been deleted.
Include flags in repo update checks indicating whether a database table
that was previously supposed to be removed was removed and whether a new
table was created. This should help us figure out whether we can safely
perform schema update steps or whether we need to figure out why some
schema update steps aren't being applied.
Prior to fdfa8052d1, it was possible to create an item in a feed
library using Add Item by Identifier. If you did that, and then copied
it to a collection in your personal library, it would somehow end up
with an owl:sameAs relation to a `/users/local` URI (probably because
the URI functions don't work properly on a feed library).
This will clean up such relations in a schema update.
- When changing type based on 'type:' line, move existing fields that
are no longer valid to Extra
- Remove 'type:' line with CSL type if the item's existing type is one
of the types mapped to it
