Create an Accounts table in DB, which will become the SSOT of the account list in the future.

Context: Currently the AccountManager is used to store the list of accounts and associated data. When the account is lost in the AccountManager, it's also not available in DAVx5. Instead, DAVx5 should contain all information about accounts and be able to create them on demand in the future.

The plan is to

1. create/update/delete Accounts in the DB whenever a DAVx5 system account is created/updated/deleted,
2. have a migration that copies DAVx5 system accounts into the Accounts table.

So we have then an up-to-date Accounts table in the DB, but all logic still uses the system accounts. (Scope of this issue).

Then we can gradually move the DB, until we only use the DB and dynamically manage the system accounts. (Scope of future issues)

Depends on #936
Depends on #878

• Make sure that AccountRepository is the SSOT for accounts¹.
• Create Accounts table in DB.
• Phase 1 (covered by this issue/PR):
  • AccountRepository uses the system accounts as actual source of accounts.
  • However it makes sure that returned accounts also exist in the DB so that the DB contains a reliable second data source. We can switch the ordinality later without risking wrong data.
  • The cleanup worker cleans up orphaned database entries.
  • AccountSettings still use the system account.

Special cases to pay attention to:

• Syncs may have an account name from the worker input/sync framework, which should not bypass the AccountRepository.
• The database may be reset (app reset) without accounts being deleted. This should not lead to an inconsistent/undefined state.
• System accounts may be deleted (explicitly by the user, or for instance they vanish through system updates, safe mode, …) without the database being reset. Shouldn't lead to an undefined state, too.

Future (not covered by this issue/PR):

• We can switch AccountRepository to use the DB instead of the system accounts.
• Then the DB is the primary source of data, but we have to make sure that returned accounts also exist as system accounts.
• The cleanup worker cleans up system accounts instead of the database.
• DB services reference to DB accounts and not to system accounts.
• AccountSettings should be stored in the database. Store AccountSettings in DB #935
• Workers can reference the service ID as input data (instead of the account + service type).
• Make system accounts even invisible in Android Settings / accounts as they're managed automatically

¹ in no way related tolocal address books (address book accounts)