Separated some classes non-related to Color sample to separate assembly
Moved to VS2013
Added to .gitignore
Added new project for WPF app with basic implementation of AdvTextBox control
Hopefully full implementation of the custom pattern
Cleanup MSTest leftover garbage
Now it seems WPF require some additional code to work with custom patterns.

The problem is that AutomationPeer implementation filters requests for patterns only to those belong to PatternInterface enumeration internally. Actually it checks against static private Hashtable which is filled in AutomationPeer static ctor - if requested pattern isn't found in the Hashtable - it doesn't even call overridable GetPattern method. In order to workaround this issue AutomationPeerAugmentationHelper class was added that goes through heavy reflection to add new member to the Hashtable.

Now, another point is that UIA requires pattern implementations to be free-threaded, i.e. they could be called from any thread, not only UI one. With default patterns, AutomationPeer handles thread questions itself as well as handling exceptions and re-throwing them in calling thread as appropriate. In this simplified implementation AdvTextBoxAutomationPeer is responsible for thread-stuff itself now, so some changes there. Plus, possible exceptions are not handled at all for now. Again this is a simplification and will be addressed later. In WPF it is done via wrapper objects which are statically defined (it seems to be the main reason to not allow extending pattern list - custom ones won't have ready-made wrappers).
Added test project for WPF app that retrieves new control's AutomationElement and asks it for new pattern implementation.
Fixed minor issues