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 #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.

[r10s]

closing stale issue.

also, the issue got much smaller, as for chatmail, we do not allow to alter bcc self at all - and for the other cases, it is "advanced", and these "power users" should know what they're doing :)
we also did few complains here, maybe the issue was never that big :)