irssi: embrace the Developer Certificate of Origin for contributions

The Linux kernel started to embrace a light weight development contribution
agreement process called the Developer Certificate of Origin (DCO) circa
2004. Attorneys all over the planet have conferred a lot of respect and
appreciation for this document and it provides a light weight alternative to
cumbersome and controversial Contribution License Agreements (CLAs).

Similar to streamlining FOSS licenses we also all stand to gain from
streamlining a light weight contribution agreement process for development
and in light of this the the Linux Foundation recently has made the DCO a
standalone project [0] so that any FOSS project under any FOSS license can
take advantage of the same gains. The motivation and intent is documented
on my blog post [1] and later covered extensively on lwn [2] after
James Bottomley's talk, and Bradley Kuhn went on extensively about it
as well [3].

Lets take advantage of the new shiny DCO and embrace it for contributions.

[0] http://developercertificate.org/
[1] http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html
[2] http://lwn.net/Articles/592503/
[3] http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
irssi core: add window console set active support

We can't go to the console window easily right now, we'll
want this in case irssi needs to prompt the user for something
sensitive such as a password.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
irssi core: enable prompting for client certificate password

irssi supports letting you specify the client SSL password
using the ssl_pass primitive on the configuration file. Its
a terrible idea to be putting passwords on unencrypted files
though so some security rational folks won't ever want to
do this. This adds support to irrsi so that if an SSL client
certificate was supplied and if no password was set we prompt
the user for one.

Upon disconnects we won't have to re-enter the password but
just in case for whatever reason SSL needs it we redraw the
screen to the console screen should the user have to enter
a password again. Users that do not have a password on the
SSL client certificate can just either enter an empty
password upon the prompt or set an empty password on the
configuration file. Its a bad idea to be using passwordless
client certificate files anyway, so let them do a bit more
work.

We only prompt for a password if and only if the client
certificate was set, if you have different client certificate
files or use the client certificate for different connections
you'll be asked for a password for each server SSL connection.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>