Complete LExSIS transpilation

[alfredats]

Currently it only works with rps.l4, am in the process of completing it for r34.l4

Will be logging progress here, along with any issues that pop up.

[alfredats]

The current LExSIS transpilation process takes class definitions as defined in l4, and transforms them into the necessary data elements as specified by the LExSIS specification.

The current version of r34.l4 existing in the baby-l4/l4 folder is encoded in a way that does not translate into the expected LExSIS output. The main issue is that relationships between classes within the l4 encoding is not properly defined. There is also the fact that there are attributes that have s(CASP) encodings containing clingo variables not encoded within the l4 file (see "detracts from legal profession" within the LExSIS file), and that some encodings of child elements are unary, while some are binary, without any indication as to which should be which.

I'm currently trying to rewrite the class definitions in a way that make sense, but find myself wanting a graph-like structure that would clearly delineate relationships between classes.

To tackle the unary/binary encoding issue, a naive idea would be that class attributes can have an un_ or bi_ prepended would help with determining the arity of the associated s(CASP) encodings. This feels like a band-aid measure, but perhaps it'll hold as a stopgap for now until a better solution can be decided on.

---

Rewritten classes here

[alfredats]

At this point i've further refined the class definitions for r34.l4 and added some lines regarding declarations in preparation for support of output enum lexsis types.

The output for the cardinality/arity headers has also been updated slightly (thank you nlg-team for the arity tip),Boolean type blocks no longer output a cardinality header, while current behavior for String type blocks has been retained.

"type" header output has also been fixed, and no longer outputs "type: string" for all blocks. At this point we have support for "string" and "boolean", and further support for the other types will progressively be added.

The current source header behavior is slightly different from that of the r34 yml file in smucclaw/docassemble-l4. The r34 yml file replicates the "position" data element entirely, twice, within the file. However, the l4 transpilation generates the "position" datablock as a root block of its own, and any blocks that require "position" data would refer to it with the "source: position" header-value pair. I'm not sure if this behavior functions properly within the lexsis -> docassemble process, some testing is needed.