feature/new parser on kore

**please review** @dwightguth 

A bit of context:
take textual full K outer definition ( with KAST inner)
->
KIL outer + bubbles
-> via KIL-to-KORE
KORE outer + bubble
->
parse KAST bubbles with new parser using a KORE outer definition of KAST (from kore.k)
->
complete KORE :-)

@radumereuta, this is the work we did last week. I fixed some tests and cleaned up a bit. have a look and adjust as you see fit.
I agree I should add more javadoc and comments here. 

> Just adhoc Scala code

I take pride in my code. I'm not claiming perfection but, aside from the lack of documentation, could you please explain what is ad hoc about this code? 

> which could have just as well be Java

Actually, not easily. We needed the Poset for the subsorts exposed by a `Module`. We initially tried to use the existing poset implementation, but it is not that easy. The problem is the kore classes are separated from the rest of the code base. The kernel module depends on the kore module. This means that we cannot use any existing Java code from within the KORE classes. They can be used by other classes but not the other way around. So, the options were to either implement a POSet, or create an interface and add a poset factory as a parameter to the Module class. The latter would basically means adding a lot of abstraction machinery for a very simple thing. So I chose to simply implement the POSet by the KORE class. Other classes in KORE will likely need it (we'll need also a labels POSet soon) so this is keeping complexity down overall.

> I don't know about others, but I am personally tired of having this discussion over and over again. This slows us down and we've got lots of things to do. You got the maximum you can get wrt Scala for now. 

I am not asking for anything more regarding Scala. I'm just trying to implement things in the fastest cleanest manner possible, while making sure that anything I do will be very usable for developers trying to use the KORE classes from Java. I'm not taking here about names, which can be easily changed (e.g., for the POSet we'll need aliases for the <, >, and ~ methods as Java doesn't allow method names like that), but higher-level decisions regarding how things are put together.

So far this means I've implemented in Scala everything related to KORE classes and their supporting infrastructure (visitors, underlying data structures, etc.). I use Java for everything that uses the KORE classes for a specific purpose, e.g., compiler passes.

Is this different from our understanding? I'm really doing my best here and these discussions slow me down also. 

> We may re-evaluate the situation after we have a clean, KORE based implementation that works well. Maybe K 5.0.

I was hoping K 5.0 would be implemented mostly in K.

In any case, if you prefer a specific different solution for this specific issue, let me know and I'll implement it.