DO NOT MERGE: Swap out existing CBN text editor UI with AvalonEdit UI

This submission is a work in progress to replace the existing CodeBlock Node text editor UI, which is a standard WPF TextBox with an AvalonEdit UI (called TextEditor). 

Why is this needed?
AvalonEdit is a WPF based text editor library with several useful features such as syntax highlighting and code completion. It has been therefore been chosen to replace the existing editor UI used in CodeBlockNode in order to leverage these built-in features with minimal implementation overhead. 

This submission therefore sets the stage for new CBN features such as syntax highlighting and code completion.

Task Status:
The new AvalonEdit based CBN is fully functional (although regression testing yet to be done).
WIP: It needs some additional tweaks to the UI in terms of styling and font size, etc. to match it with the look and feel of the existing  CBN UI.

Implementation Details:
The new class named "CodeBlockNodeTextBox" that inherits from ICSharpCode.AvalonEdit.TextEditor replaces the existing "CodeNodeTextBox"

What is the impact of this change?
Memory and performance profiling was done before and after the swap to check the impact of using AvalonEdit and it was found that there was no significant performance impact in the UI. As for memory, it was not found to be very heavy either. For a 100 codeblock nodes, AvalonEdit was found to be only about 6MB heavier than standard WPF.

AvalonEdit Memory Results [100 Codeblock nodes]:
![image](https://cloud.githubusercontent.com/assets/5710686/4007961/c7c48f9c-29ce-11e4-9cf4-3480820ebc93.png)


WPF TextBox Memory Results: 
![image](https://cloud.githubusercontent.com/assets/5710686/4007969/f04abaf4-29ce-11e4-8c3b-472a21ed70e7.png)
Hi Aparajit, following the pattern of constructing a ```View``` (for this case, the ```CodeBlockNodeTextBox```) I'm wondering if we could pass in the corresponding ```NodeViewModel``` through the constructor? Every time I see ```FindUpVisualTree``` it feels (to me) like we are trying to gain access to things through a *back door*, indicating likelihood of a design problem.

Of course some would argue that ```CodeBlockNodeTextBox``` is not strictly a view of the ```NodeViewModel```, but it seems like we could use the constructor to ensure that we are only able to construct this ```CodeBlockNodeTextBox``` given a ```NodeViewModel```. Then we could save those ```null``` checks (I mean, what then, if we cannot find a ```dynNodeView```?).

When that's done, this properly can be removed.