Adds the first stages of test stub compiling


Copied from the bigger thread

So if you don't write a test stub then you are saying that you don't want to make your control testable (which I think is bad). I think its good to know that a sub control is not testable and we can add an override to say ignore testing it as a last resort or a way to override the type and provide an empty test stub class. You are also not required to build the testing code (aka you don't functionally test your code). Also if you have custom Views (not from template) you should ideally make a custom Test Stub that way others can test the code after your control (otherwise you control has made a black hole of testing under it, hurts reusability). This is also important since all of the controls that have custom views have interesting testing hooks (List, repeater, etc) and. They are also the most common area where test reliability will be affected because they have non trivial renderings and possible have async code or complex control look ups (type validation in content controls, waiting for content to render in the async list view, etc). We already know that list view has a lot of functional test holes and its important to understand how to wait correctly for elements to show up in the list view. We also haven't validated how to do scroll correctly and reliably. The person who is best suited to solve this though is the control creator since they understand how the control works and knows what is async and what is not. This probably easy for the control creator since the solutions are not hard but someone not familiar with the internals of the control has to learn the control to understand how to safely test it. So hopefully the control owner doesn't pass the buck and makes the control also easily tested.

So high level thoughts:
 Every control should be testable.
 We should compile error ifthere is not a test stub (generated or manually created). We should allow people to say in their template that they want to suppress the stub linking but really the control owner should make a test stub even if its empty for there control (like two lines of code "class MyControlTestStub extends ViewTestStub {}" "export MyControlTestStub").
 Test stubs live right next to the view since the generated ones will live right next to the view too.

I think this model fits well with letting the toolkit scale up with the scale of your app. In the beginning functional testing probably isn't needed but as your app matures and gets more complex it start becoming required. And you want to understand what holes you have in the testing and fill them but ideally if they are using existing provided core controls (ListView, Repeater, etc) there are no wholes and they can just start writing test cases.