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.
Okay, yeah, I guess I can follow this as having the desire to create an
immutable poset. @grosu, I am fine with this use of Scala as explained to
me.

On Mon, Dec 22, 2014 at 1:50 PM, Cosmin Radoi <notifications@github.com>
wrote:

> In kore/src/main/scala/org/kframework/POSet.scala
> <https://github.com/kframework/k/pull/1264#discussion-diff-22186131>:
>
> > @@ -0,0 +1,76 @@
> > +package org.kframework
>
> I thought about this but didn't really want to create a precedent.
> Initially I didn't like that the KORE classes cannot depend on existing
> code, but it may be for the best in order to not muddy the waters.
>
> The existing POSet implementation is pretty clean but it is mutable. As I
> need the poset as a field of an immutable KORE class, I wouldn't plug it in
> directly. One way would be to use it to compute the transitive closure,
> then wrap it in an immutable data structure. The the Java POSet object will
> only live during the computation. I didn't think it is worth it considering
> the simplicity of doing a transitive closure. Still, yes, it is workable,
> and I can take this path if it pleases people. Let me know.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/kframework/k/pull/1264/files#r22186131>.
>