ibus: a key stands for the FocusIn a client may never send

A context that had not sent FocusIn had every key rejected outright, so
the input method was silently dead in a client that omits or delays it,
and in the documented case of two applications whose focus events cross.
ibus-daemon and fcitx5 both treat a key as focus; strans, which plays the
daemon here, now does too.  A release still does not focus, and the
engine's own owner rule is unchanged.

ibus.c

@@ -526,11 +526,16 @@ dropconncontexts(DBusConnection *conn)
 			dropcontext(&contexts[i]);
 }
 
+/*
+ * A key is proof of focus: some clients never send FocusIn, and the
+ * focus events of two applications can cross.
+ */
 static int
 processkey(Ictx *ctx, u32int sym, u32int state, Keyres *res)
 {
-	if(state & Relmask || !ctx->focused || hidden(ctx))
+	if(state & Relmask || hidden(ctx))
 		return 0;
+	ctx->focused = 1;
 	sendrequest(ctx, Keypress, ipckeysym(sym, xkb_keysym_to_utf32(sym)),
 		ipcmod(state), res);
 	if(preowner != nil && preowner != ctx)