let `dc_check_qr` and `dc_join_securejoin` accept invite-links

[r10s]

1.44 aims to focus more on invite-links (see https://i.delta.chat and https://github.com/deltachat/invite), meaning that eg. copy+paste will use invite links and not plain (otherwise mostly useless) OPENPGP4FPR-links.

as pasting links uses the same flow as scanning a qr code (so, dc_check_qr followed by dc_join_securejoin), both functions should additionally accept invite-links and handle them as OPENPGP4FPR-links

technically, they are mostly the same, to turn an invite-link to an OPENPGP4FPR-links:

• replace prefix
• replace the first & by #
• leave everything else alone to allow future parameter changes (also groups already have more)
• from UI perspective, nothing must change, just DC_QR_ASK_VERIFYCONTACT or DC_QR_ASK_VERIFYGROUP is returned

note, that existing OPENPGP4FPR-links are not replaced; they are still used as is in QR codes.

example:

https://i.delta.chat/#FINGERPRINT&a=ADDR&n=NAME&i=INVITENUMBER&s=AUTH
OPENPGP4FPR:FINGERPRINT#a=ADDR&n=NAME&i=INVITENUMBER&s=AUTH

[r10s]

@iequidoo great you pick that up! ❤️ so i can concentrate on other things.

i just had a closer look at the code, seems it's mostly about calling decode_openpgp() also on the prefix https://i.delta.chat in check_qr() - everything else seems to be routed correctly then.

when adapting decode_openpgp(), let's also be tolerant for the first slash, so https://i.delta.chat/#FINGERPRINT&a=ADDR&... and https://i.delta.chat#FINGERPRINT&a=ADDR&... both work (regarding #1969, these things are a bit unsharp in practise :)