Support reading and writing Zipline APIs as TOML

[swankjesse]

I didn't introduce a dependency on a 3rd-party TOML library. I'm open to this, but it might make it difficult to write comments. (I'm less concerned with reading comments.)

I'm also anxious about how any dependency will interact with Gradle's classpath.

[JakeWharton]

I'm also anxious about how any dependency will interact with Gradle's classpath.

This is why all of Redwood's build logic exists in an executable jar because it gets its own classpath completely divorced from the Gradle build.

You may also have problems with your use of the embeddable Kotlin compiler in the other PR and mixing it onto classpaths with the Android Gradle plugin and its use within lint.

I didn't introduce a dependency on a 3rd-party TOML library. I'm open to this, but it might make it difficult to write comments. (I'm less concerned with reading comments.)

Yeah writing with comments would always have to be done manually. I assumed you'd use one for reading it back, though since parsing is 1000x more code than a bunch of appends. Don't really care either way as the code should basically never have to change once it's working.

[swankjesse]

Fortunately the embeddable compiler is a compileOnly dependency. But I dig your strategy of forking to a CLI. I’ll do that too.