Expire stale `bobstate` rows eventually

This is a follow-up to https://github.com/deltachat/deltachat-core-rust/pull/6534

Currently it is not a problem that QR codes scanning process may get stuck when Alice never replies, because there is always at most one row in `bobstate` table and next time bob scans a QR code, all previous processes are aborted.

With https://github.com/deltachat/deltachat-core-rust/pull/6534 the table can theoretically become large if Bob scans thousands of QR codes from Alice's that never go online. I don't want to do anything about this in #6534 to avoid adding migration and fixing it is not urgent because this is unlikely to become noticeably slow in real usecases.

Still, I think we need a migration with a properly designed table that stores auth codes and Alice fingerprints for outstanding securejoin processes when Bob scans a QR code and does not have Alice's key yet. The table should also probably have a flag for whether the process is a group join or contact request, maybe chat ID and a timestamp of when `vc-request` or `vg-request` was generated. If the process is outdated by something like 30 days or timestamp is invalid (is in the future), the row should be dismissed.

Old `bobstate` table should not be deleted for compatibility, but can be cleared once during migration.