Break out each assertion into its own test

By using a test case source, and building up an Action object to run for
each test case, each test case can display as a separate test in NUnit.
Reporting can be done more easily, as the NUnit reporting is now fairly
complete, although individual tests don't display very well in the tree
view. It also makes it possible to filter out the tests on the Spec
class itself, thus making full test runs against the SpecEasy solution
possible. If we were to remove the ability to check exceptions in a
delegate, and just have an expected exception type, we could also use the
NUnit expected exception handling.

Note that this does have some interesting side effects. First of all,
because tests are completely built up in advance, test order is less tied
to order in the code, and so should not be relied on. Additionally, test
code that is not in a Given/When/Then will get run during test
construction, but not during test execution. So member variables that are
reset in test code outside of a given/when/then no longer work. The tests
that relied on this behavior have been fixed in this change, but other code
may rely on it as well, and would need to be changed accordingly. Overall,
this is a good change, as it more clearly delineates code executed during
tests and code executed to create the test cases.
Merge pull request #19 from rockhymas/master

Break out each assertion into its own test
Merge branch 'ronrat-master'

Conflicts:
	SpecEasy/Spec.cs
missed a bit of the merge
Support for async
Added support for async test specs as well as thens, givens, etc.
Created Unit Test for Async Methods
Merge pull request #23 from articulate/UnifiedAsync

Support for Async Methods
Updated nuspec and assembly info for 2.0.0 build.
Show example of BDD-style assertions.
Use the "Should" library in SpecEasy.Specs as example of BDD-style assertions
Clarify usage of Should library in examples
Merge pull request #15 from mmertsock/should

Show example of BDD-style assertions.
Fixed missing character in class name
Solution would not build in VS 2013 and ToolsVersion="12.0" because the NuGet target was using the correct tools path but the wrong Tasks dll name. See http://stackoverflow.com/questions/20661943/build-on-tfs-2013-failed-but-okay-locally