Store data in database (TypeORM)

[hesyifei]

Previously all the data are stored as JSON.stringify string in Async Storage. This PR uses TypeORM with Expo SQLite to store pings data and answers data in the database. Each study will have its own SQLite file, and in the file, there are two tables: ping and answer. Refer to PingEntity and AnswerEntity for details.

The types Answers are replaced by the classes AnswerEntitys. The type PingInfo is replaced by PingEntity.

Async Storage no longer stores PingInfos, but is still used to store SurveyScreenStates. It means that AnswersList exists both in state (and hence the Async Storage that stores all SurveyScreenStates) and the database. This decision was based on the following reasons:

• Many of the existing functions and components relies on synchronous loading of previous answers, whereas loading from database has to be asynchronous.
• It makes reloading back to the current state after the user exits the app easier.
• It serves as a backup to the database.

It means that we get all ping info from the database, get all answers info from the state during the survey, and get all answers info from the database during data upload. Notice that we .save() an entry in database first, then .reload() and save it to the state. This is so that our data in state can match data in database, hence making the code less prone to bugs.

For data upload, currently we upload add PingEntity[] and AnswerEntity[] as JSON (Notice this means that the data structure has changed - previous each answer is nested inside a ping, but now all answers are flattened to the same layer and identified by the composite key pingId and questionId). In the future, we might consider directly uploading SQL to the server.

This provide basic support for #10.

Note: at the time of merging, there is typeorm/typeorm#6142. It should fix with the next version of TypeORM.