Don't rely on maintaining a list of test files, it's too easy to forget
one and silently fail to run it.

Probably best to avoid angering the 800 lb gorilla with access to killer
robots.

https://example.org works, this is why it exists.

Excluded: graphml XML namespaces, links to e.g. Fabric homepage

Fixes #128

Trying to diagnose a Reddit user's problem.

Need a better story (perhaps a callback function?) for handling this.

The strategy is reconstructed for every playbook that is included or
specified on the command line, therefore we can't store the global
Router there without losing all our SSH connections across playbooks.

Fixes DebOps bug.

Turns out Ansible can't be trusted to actually check the result
dictionary everywhere it expects one, so put the real exception text
into -vvv output too.

Might want to de-overload the meaning of whitelist in future, but in
the meantime it works fine for Ansible and I can't think of a
whitelisting use case that would break because of it.

Closes #114.

Cuts down on even more spam

Was causing tons of log spam due to 'skipping absent related name'

Amazed this one managed to scrape through for so long. Calling
__import__ from within find_module() was causing the target module, in
this case cookielib, to be loaded *then overwritten* by a subsequent
duplicate load higher in the stack.

The result is that cookielib was loaded twice, and, per usual Python
import semantics, a reference to the partially initialized first
cookielib was installed in sys.modules while its code executed.

At the end of cookielib on 2.x, it imports _LWPCookieJar, which in turn
imports the partially built cookielib from sys.modules, then subclasses
the CookieJar from /that/ module.

Everything is wonderful. Then the call returns back up into the import
mechanism which restarts the entire process -- only this time,
_LWPCookieJar is /not/ reinitialized, so the copy in sys.modules is
still left with types pointing at the old module!

So the duplicate import creates a new CookieJar which is not the base
class of LWPCookieJar. Tada! 3 hours debugging.

This is probably a performance fix in disguise, didn't realize things
were so broken. It may also be a regression elsewhere. Urgently need to
finish the tests.

Could it be that some empty dict magically gets populated from somewhere
invisible?

It's a magical switcher that needs argv[0], which we don't provide.