deal with disabled `bcc_self` after successful backup-transfer

[r10s]

if setting up another device succeeded, but bcc_self is disabled, this will cause problems in all situations the user wants to use two devices afterwards.

while since 2 years, the default is "enabled", there are still older installations - and for some providers, we use a different default (eg. nauta has bcc_self disabled by default) - so we can expect this to be an issue on quite some installations.

options to deal with that would be

(1) enable bcc_self after a successful transfer

(2) add a warning if bcc_self is disabled after a successful transfer (we should make sure, the warning is not notified or so during transfer, for the warning itself, we can just reuse maybe_add_bcc_self())

at https://github.com/deltachat/deltachat-core-rust/pull/825 we decided not to change bcc_self for the autocrypt setup message, because of leaving user decisions alone, and decided for (2) - not sure if that is still a valid argument for backup-transfer, which seems to be much more related to actually using a seconds device.

[iequidoo]

(1) enable bcc_self after a successful transfer

Better before. From the viewpoint of the sending device it can fail, but actually may succeed because of the failure of final status reporting :) And we can show also a message to a user "bcc_self was enabled because..." EDIT: And if enabled before the transfer, no fixup is needed on the new device.