Add tests to verify that #17 is fixed; cateorize tests by expected result

[CharliePoole]

I verified that the use of nunit.core.engine fixes the problem of not finding the config file. That's as expected, since the engine includes that function and the old adhoc code didn't.

I added a couple of tests to NUnit3TestDemo to demonstrate that this works. Since the demo includes many tests that are expected to fail, etc., I also added a custom attribute to indicate what is expected to happen for each test. It's called ShouldAttribute and creates a property that Visual Studio can use to categorize the tests. It has already helped me discover two problems with how tests are being reported to VS and I'll write issues for them.

I'd like to merge this and release so I'll leave a short window for review, but because it's only the demo code that is changing I won't wait a long time. :-(

[OsirisTerje]

This is only demo-code but it may still be used as guidelines. I don't think use of strings as parameters should be encouraged, when it is sprinkled all over the code. Could this be solved just as well by using distinct properties, one for each case: ShouldFail, ShouldIgnore, ShouldPass and so on, and just pass the string inside them to the base in the ctor ?

[CharliePoole]

I had it that way originally, as custom category, and then switched to a property, primarily because of how VS displays it. For categories, you get Category [ShouldPass], etc.

I could certainly make separate property attributes for each outcome.

BTW, I never thought of this as a model for other people, but I suppose it should be taken that way. I use it as my primary acceptance test for the adapter.

[CharliePoole]

@OsirisTerje I changed it to have separate attributes as you suggested. Used "Expect" rather than "Should" since it makes more sense with Inconclusive and Mixed.