Restructure nodes to avoid parsing in encoders

[Strixpyrr]

There's still some remaining parsing code in node constructors making encoding awkward. For example, to create a table, you have to pass a header string to be parsed, rather than the table's key:

val table = TomlTablePrimitive(content = "[$key]", /* ... */)

The base TomlNode class has a content property in its primary constructor which is unused except for exceptions and pretty-printing. For inline tables, I've passed an empty string for this. For other pairs, it's formatted in the constructor. Since it's only used for debugging and exceptions, would it make more sense to create these as needed?

The lineNo property also seems to be exclusively used in exceptions.

TomlNode also keeps an instance of the input config, used in insertTableToTree to construct sub-tables, and TomlInlineTable.returnTable. If these functions used a non-parsing constructor, this may be avoidable.

Somewhat related is the usage Any in TomlValue rather than the actual value type. Differentiation between constructors in the case of strings will be difficult. Maybe that's a separate issue though?

There's probably something I missed

[Strixpyrr]

Might as well bring in #75 too

[Andrey Kuleshov]

Somewhat related is the usage Any in TomlValue rather than the actual value type. Differentiation between constructors in the case of strings will be difficult. Maybe that's a separate issue though?

That's actually a very good point. I also do not like it , but do not know how to fix it easily: we definitely need some super class in this hierarchy (as parsers usually do) with content.

So if, for example, you need to work with a content of your abstract Value Node (foo(value: TomlValue)), you would like to use value.context.

[Andrey Kuleshov]

The lineNo property also seems to be exclusively used in exceptions

Speaking about lineNo - actually it is a part of debug info and mostly all Intermediate Representations should store it (just in case or for debug purposes).