Add dynamic TestCase class generator.
Add dynamic TestCase class generator.

This is not *strictly* necessary; however, the previous manner that I
had devised for running the old unittests in lib/bridgedb/Tests.py had a
small problem: it ran *all* the tests in lib/bridgedb/Tests.py as a
single trial test. This meant that if a single test from Tests.py
failed, the whole test would fail, which doesn't give us very
fine-grained reporting, especially if there were multiple failures (the
whole thing would fail when the first one failed).

To fix that, it would be necessary to create one `TestCase` "test_*"
method per original unittest. Each individual unittest would also need
to be wrapped with a `twisted.trial.unittest.PyUnitResultAdapter`, in
order for twisted.trial to be able to capture tracebacks and
`failure.Failures` correctly. Additionally, it would be nice if we could
simply take each `TestCase` method from the original unittests and reuse
their method names (so that we know exactly which one of the original
unittests is being run); therefore, the methods need to be wrapped yet
again to reassign dynamic instancemethod names. (Normally, dynamically
mucking around with Python's namespace is a BadIdea™, but it turns out
not only that this works, but that it *also* works with the dynamically
discovered doctests from `test_Tests.generateTrialAdaptedDoctestSuite()`
as well!)

I mostly wanted to see if I could do it. Turns out, I can, and it seems
to work well. This black-magic encrusted monster I've munged together,
`DynamicTestCaseMeta`, works in the following manner:

  1. It generates dynamic methodnames with a given `methodPrefix`

  2. It generates corresponding methods for a
     `twisted.trial.unittest.TestCase` base class.

  3. Next, it wraps the generated methods. Sometimes, depending on the
     base class, it wraps them multiple times. It also allows further
     layers of wrapping, i.e. the `MonkeyPatcher` returned from
     `monkeypatchTests()` still works.

  4. Then, it assigns each generated methodname and method pair, using
     the special __new__() constructor, to the base class *when the base
     class is compiled* (i.e. when the test_Tests module is first
     imported into a Python interpreter). Therefore, each time you
     initialise a base class which uses `DynamicTestCaseMeta` as its
     __metaclass__, every initialised instance will have the *same*
     generated code, because the code which is generated is decided at
     compile time, not access time.

 * ADD the terrifying `test_Tests.DynamicTestCaseMeta` class generator.

post scriptum: Take that, C++! :P

wfn/bridgedb,pagea/bridgedb,mmaker/bridgedb,mmaker/bridgedb,pagea/bridgedb,wfn/bridgedb