modularize client authentication handlers

[Antoine Martin]

The same way this was done for the server modules. The modules can then be configured more easily using the challenge-handlers string.
Making it easier to test and to implement new ones (ie: "exec" handler which calls an external binary)
We can also define a clearer interface so modules can claim a particular challenge mode, or be used as fallback.

[Antoine Martin]

See also #1861

[Antoine Martin]

At the moment, the process_challenge_uri comes first and is only used once: we clear the password value after use to give the other authentication handlers a chance to run. (details and examples in ticket:1691#comment:8)

The other handlers behave differently... for some this doesn't matter too much (ie: prompt), but for others this prevents other modules from being tried (ie: file, env, etc)

[Antoine Martin]

Done in r22711 + r22713 + r22714 + r22715.

All the authentication handlers now live in xpra.client.auth.*.
Each instance can be configured separately, and the same handler type can be used more than once.

Examples:

• authenticate using "env" module twice:

  PASSWORD1=foo PASSWORD2=bar xpra attach tcp://192.168.1.7:10000 -d auth --challenge-handlers=env:name=PASSWORD1 --challenge-handlers=env:name=PASSWORD2
  

• use a password file (--password-file command line argument is deprecated)

  xpra attach tcp://192.168.1.7:10000 -d auth --challenge-handlers=file,filename=pass.txt