Migrate to Core Data object model

[ShezHsky]

From #493:

Drop abstraction layers in model around objects and expose new NSManagedObject subclasses for entities. The model package will continue to own how we create, update and fetch them. Gradually move more behaviour into these objects (as with the current model refactor).

Define a new model using Core Data that produces an object graph for use within SwiftUI. The new model will be made available into SwiftUI's environment for rendering within views, swapping the app from MVP to MV. The model will continue to own almost all the complex logic around the app while the view provides structure for displaying the objects and routing between pages.

Work began on this in #497 with the definition of the model. Remaining tasks include:

• Fetching images and caching within the app container, persisting the URL of the image within the Image entity base class
• Handle deletion of individual entities in sync responses, and keeping the object graph in shape (e.g. deleting an Announcement should also delete the corresponding image entity and image on-disk)
• Handle re-insertion of entities when the RemoveAllBeforeInsert key is true in the synchronisation payload
• Sync private messages from the API, potentially caching into the persistent store
• Incorporate the configuration from Firebase. This currently provides us with the convention start time. The model should perform this load in parallel with the store update.
• Perform a performance audit using a performance test and instruments. We'll almost certainly need a few indexes handy for attributes we're querying
• Expose previewing model for development of SwiftUI views that uses an in memory store with data fed from response files

Once the above are complete, we can begin to spike integration amongst various SwiftUI views in the variant.

[ShezHsky]

Addressed deletions in #501

[ShezHsky]

Message syncing addressed in #503

[ShezHsky]

Remote configuration addressed in #504

[ShezHsky]

Previewing addressed in #506