Add support sufficient for kpmenu-server use external auto-type program

[xxxserxxx]

This is to track a solution that would address #3 without adding (significant) complexity and additional security attack vectors to kpmenu.

To summarize, adding autotype support to kpmenu has both UI design challenges (autotype is hard to make robust in the face of arbitrary Javascript-driven web login pages) and security concerns (kpmenu's client/server design precludes any client-side solutions). Instead, this ticket would see the kpmenu server able to call more complex prompts sufficient to code the autotype solution (or solutions) in external code.

[xxxserxxx]

A current proposal is to modify PromptPassword() for a second modal that 1) calls out to a program with information sufficient to match windows, 2) uses entry configuration to determine the autotype attribute set, and 3) interacts with the external program enough to pass multiple values to it.

The requirements are that

1. the kpmenu security model is preserved; that is, the server controls which program gets sensitive information;
2. the external program needs enough information to identify the destination application; this is, at the least, GUI window identification information, but could also be user list selection (dmenu/rofi), user UI selection (click-on-a-target-window), or something else.
3. the external program needs to receive the resulting sensitive information so that it can perform autotyping. Examples are: pasting; autotyping; and browser plugin communication.

[xxxserxxx]

Update as I'm looking into this some more. It would be more efficient to ask kpmenu to do the matching, rather than send a large chunk of the DB data to an external program. Therefore, the sequence would look more like:

Internally, if the autotype trigger call includes a window title argument, kpmenu will try to match it against Entrys in the database; otherwise, it'll open a standard "choose an Entry" prompt. Once it has an Entry, it'll Exec a pre-configured program that'll do what it needs -- either the quasi-auto, interactive UI entry, or just full-on autotyping like KeepassXC. It shouldn't be difficult to implement both options.

And, per #3, I'll code the kpmenu part to match against Entry.AutoType.Association.Window if it exists, and Entry.GetTitle() if it doesn't -- the current KeepassXC behavior. I'll also use the KeystrokeSequence if it's defined, but I'm not sure how much of the macro language I'm going to implement, because (as I said) I believe it's an error-prone solution and I may not have enough interest to implement everything.

@AlessioDP, for the quasitype executable I think it'd be best to keep it in a separate repo because it'll probably pull in some heavy dependencies (robotgo isn't exactly light), but if you don't mind it in this repo I can add it here.

Edit Updated the diagram to make it clear that we don't pass data on the command line where it can be inspected via ps

[AlessioDP]

I prefer a different repo too ;)

[xxxserxxx]

Can't use Entry.AutoType.Association.KeystrokeSequence at the moment because of tobischo/gokeepasslib#68, so I'm hard-coding it to the default.