First shot at a v2 framework driver

**Updated**

This PR is for general design and code review only. There is still work to be done.

The PR implements a framework driver, which is able to load, explore and execute  NUnit V2 tests. The code is an adhoc spike, without any tests.

The code uses the nunit.core and nunit.core.interfaces assemblies from the existing pre-release build of NUnit 2.6.4. The assemblies have been added to the repository in the lib directory. It would be better to use NuGet to get these assemblies, but there is no package that includes them in the correct way.

I placed the driver in a separate assembly built as a part of the main NUnit solution. It references only one engine interface, IFrameworkDriver, defined in nunit.framework.api.  The NUnit3FrameworkDriver class calls into the NUnit V2 core assembly and explores or runs the tests, using the static ResultBuilder class to create the XML output string that is returned. There are still a few unimplemented methods.

ResultBuilder is very procedural and uses an XmlWriter to output everything. This turns out not to work so well for V2 to V3 translation as it does in the opposite direction. That's because there is more info needed for the individual V3 nodes than can be found in the V2 nodes. For the next commit, I intend to replace ResultBuilder with a class that loads all the results as a document, fixes it up and then creates the return string. This should allow me to fill in the counts of passed, failed, etc. tests in each suite, which I wasn't able to do with a single pass.

A few things will be absent from the output, by design:

* The seed used to create random values for each test is not a part of NUnit V2.
* NUnit V2 results do not have a start or an end time.
* Text output is not part of the V2 result, so there will be no Output element.

These elements and attributes will simply be missing from the output and the V3 engine and runners will have to deal with their absence.

**What to Review**

Please look at the overall approach and the future direction described above. Consider the code in ResultBuilder.cs as temporary.
Should this use the common assembly info? Should it be versioned with the rest of the framework, or match the 2.x framework?