Add optional `&clientkey=...` to NIP-46

[fiatjaf]

trafficstars

This allows a single bunker://... string to be self-contained, storeable and pre-authorized.

closes https://github.com/nostr-protocol/nips/issues/1106

[mikedilger]

I'm ok with this but as implied by @brugeman, specifying the client key directly leaves an infinite window for a leaked key (via a leaked bunker URL) to be used by an attacker, whereas specifying the secret and having it consumed closes that window during the connect. Maybe that isn't concerning to some, which is why I'm ok with this, but I prefer the connect sequence even with the extra round-trip.

[fiatjaf]

Yeah, maybe people can use persistent secrets if they want this functionality.