DebugEngine refactoring and optimization

And here we have the last piece of the puzzle. Took a bit longer than expected, but I am happy about the final result. Please review it and let me know, if you see any more changes required. It should also greatly improve your (and mine) further development due to introduced simplifications (change log below) and bug fixes. I am very close to a state, where I could start using it personally ;)


Change log:
 * introduced new registration attribute for DebugEngine - so now, it's not needed to have separate .reg file to manipulate system registry to have it visible in Visual Studio
 * enabled feature to start debugging the DebugEngine and its communication with GDB on the fly (simply press F5, while NativePlugin solution is open in one instance of Visual Studio and then open any BlackBerry sample project in spawned instance and start debugging it on a device)
 * refactored several times the DebugEngine project itself, introducing: unified naming convention, better class separation (by making most of the fields private), arguments verification and eliminated all the potential places suggested by R#, that could throw exceptions
 * dynamic expression evaluation doesn't spawn new thread now (uses one from default .NET thread-pool)
 * fixed selection of stack-frame in GDB, so now, it shows dynamic values for local variables correctly
 * fixed some exceptions, caused while parsing data from GDB (after parsed by parsing-instructions)
 * removed all the spin-locks (aka Thread.Sleep(0)), what greatly improved performance
 * renamed GDBWrapper to BlackBerry.GdbHost project and improved it (by for example removal of CLR reference, logging and the way it consumes parameters)
 * GdbHost supports paths with spaces now (so developed BlackBerry project can be placed anywhere!)
 * GdbHost exits automatically, in case of GDB crash or other unexpected termination (i.e. process killed by developer)
 * DebugEngine stops the session, when GdbHost disappears unexpectedly (to improve developer experience)
 * "attach to process" suggests all defined devices
 * "attach to process" has [Find...] button disabled as default Visual Studio behavior was misleading
 * ported parsing-instructions to C# (this is really crazy, code, and I vote for removal it! check suggestions at the end)
 * introduced own way to communicate with GDB in C# (based on ToolRunners - GdbRunner and GdbHostRunner; check the overview image below)
 * introduced own clean way of sending, receiving and parsing GDB messages (GdbParser class, along with Request, Response and RequestsFactory)
 * using items above - build a wrapper class, that exposed an API defined by the old GDBParser project and was sending the same parsed responses (GdbWrapper class)
 * removed GDBParser project
 * converted all C# projects from x86 to AnyCPU architecture, since no more limited by C++ communication
 * created ToolRunner for blackberry-connect.bat (as this was done in C++ in totally different way than other used tools) and thanks to that totally removed the need of having Java installed on the machine next to Visual Studio (as it uses Java delivered in bbndk_vs folder as all the other tools)
 * introduced Targets class to manage connection states with devices and simulators
 * changed the way BlackBerry and BlackBerrySimulator platforms are added into project (now by menu option, not automatically anymore)
 * fixed starting native project with Ctrl+F5 shortcut (without debugger)
 * tests were ported to C# and few new added
 * and other small tweaks I though useful

Further developments:
 * you could 'convert' (or mostly rewrite) the current DebugEngine to use my proposed request-response architecture - used GDB requests could be wrapped in separate classes and parse messages themselves, without using the magical 'parsing-instruction'
 * or at least rules could be reviewed as they might lead to infinite parsing if they aren't ending with EOL (check this hack in GdbWrapper.cs)
 * someone could implement a better parser for GDB results; I proposed an interface only (IResult.cs), but once figured out, this could lead to much more work than I wanted to do (see points above) I didn't started doing it this way (that's why there is only ListProcessesRequest done for now); I just wanted to get rid of this C++ code
 * attaching to process could be improved; if the plugin is not loaded yet, ToolRunners might not be correctly initialized for Java paths etc leading to errors; I tried to fix it by loading plugin at Visual Studio startup, but creating an Output Debug Pane fails in VS2010, so I disable it there for now; also the [Find...] button only displays the warning message, instead it could display form similar to [Add new target device] from plugin settings
 * add more tests for GDB flows (BTW. since GdbParser is a separate entity talking via IGdbSender interface, there is already mock implementation, to have message exchanged without real GDB running and connected to the device).

All comments welcome.
 

![BlackBerry plugin Debugger Overview](https://cloud.githubusercontent.com/assets/475630/3791911/69049628-1b5a-11e4-92d3-682200059638.png)
![Requests](https://cloud.githubusercontent.com/assets/475630/3791912/6a6b61ae-1b5a-11e4-8973-089bea4cd5e9.png)