Move from database to encrypted archive

[ajburley]

The database is a non-standard format, from which it is difficult (although by no means impossible) to retrieve the data without having the original app. We futureproof the users' data by moving to a standard file format, i.e. encrypted archive. Tags will still be in a non-standard format, but stored within the same archive in a human-readable format.

EDIT: Further details on this:

• We will use Zip4j and ZIP encryption (AES-256) with the "Store" archiving method.
• Tag format: there will be a directory called tags within the archive, containing a set of text files named after each tag, and each file will contain a list of tagged files with one file on each line.
• There will also be separate folders for notes, archive and trash.
• Even after making this change, we still need to support the legacy format, not least because people may want to migrate from SealNote legacy to SealNote Plus. When restoring a database, the app needs to detect if it is in the legacy format or new format, and convert it if needed. Ideally, we will remove no-longer-needed parts of the legacy format code, but this may be split into a separate issue.
• ZIP encryption does not include filenames, so just call them 1.txt etc, and have a mapping file like note-titles.txt.

[ajburley]

Needs investigation - should we use TAR and then file encryption, or some kind of native encryption supported by an archive format (e.g. ZIP). This will depend on what's out there.

[ajburley]

Formats for file encryption are by no means standard; tutorials found on Google often suggest to the the openssl tool, but file encryption apps on the Play Store are often not compatible with the resulting format. The TAR format does not support encryption natively. Popular archive applications like ZArchiver only support encryption for ZIP and 7z formats. We will use Zip4j and ZIP encryption (AES-256) with the "Store" archiving method.

[ajburley]

Need to generate a legacy format database for testing prior to making these changes. Blocked by #53.