Debugger Refactoring

#### Overview

Suggested Refactoring for the debugger's setup. The following changes are suggested:
* A controller class (see  kernel/src/main/java/org/kframework/debugger/controller/DebuggerController.java)   introduced. This class acts as a sandwich layer between the fronted and the backend, contains common logic, and will be a part of the kernel.
* A new interface for the frontend introduced (see  kernel/src/main/java/org/kframework/debugger/frontend/DebuggerFrontend.java ). All frontends will now implement this interface. The ultimate goal is to have a plugin-like setup, where frontends are maintained independently from Kernel. Currently however, for experimental purposes, a textual frontend is included as a part of the Kernel. 

#### Implementation Details

Final aim is to have a plugin like setup, where user can download a frontend jar, and plug it into the kernel. This setup allows for the plugging in process, and makes it easier for others to develop frontends. Currently, the frontend and the backend are injected into the above mentioned controller class. For the purpose of this injection,  kernel/src/main/java/org/kframework/krun/KRunModule.java had to be modified. Please note that these changes aren't meant to be permanent yet. Later, we can have a service loader look up available frontends and inject them into the controller, allowing for the plugin and play.

#### Advantages

* Common logic between the frontend and the backend has been separated and put into the controller class. This allows writing frontends much easier. I'll be soon updating the wiki with details about writing a frontend. Also, the power of Transformations shine through. The frontend writer need not know anything about the State. In order to get a pretty printable result, he just needs to call the transformation's run function
* As mentioned earlier, it allows for plug-and-play styled frontends.
* Better integration with guice. Guice is now used for injecting the dependencies into the controller. Controlling the dependencies has become easier
* The implementation is not truly frontend and backend independent. We only need to ship the controller with the Kernel.

#### Feedback

Please feel free to provide feedback, and ask questions. Also keep in mind that changes are experimental (hence the new branch). I plan to get the required approval from Dwight before putting in more effort. However, around 80% of the refactoring has been completed. Feel free to email me, Manasvi at (msaxena2@illinois.edu).
Thanks!
this isn't right. step(0) can still technically change the resulting term.  This is because in the maude backend there is a difference between rules and equations. similarly, in the java backend a step(0) would likely evaluate functions.