Add Kotlin capability

[dmusican]

This PR adds capability to PreTeXt to handle Kotlin code. I've added an example in the sample book to show its use. If the book is built to static html, this seems to be sufficient to make everything work. For interactive code that runs on a Runestone server, there are changes that need to come to the Runestone code base... but this needs to be in place first. (I've got those changes ready to go, but I'm starting here.)

Thanks! If I can clean this up or help in some way, please let me know.

[ascholerChemeketa]

This looks great functionally. It is hard to know for sure without the RS side, but I have a high degree of confidence it is doing all the necessary things.

The only issues I see are with documentation and commits.

1. The guide has multiple spots where available languages are documented. Yes, there is too much redundancy in these - I just made an issue about that: Documentation: Redundant listing of programming languages #2720. But, for now, it would be good to list Kotlin:
   

   pretext/doc/guide/publisher/runestone.xml

   Line 31 in 612c5fe

   <li>A <tag>program</tag> element with the attribute <attr>interactive</attr> set to <c>activecode</c> (even outside of a an exercise) will be realized as a Runestone ActiveCode interactive program, where programs can be edited, compiled, and run. In some cases a CodeLens interactive trace utility is also available. The <attr>language</attr> must be set. Supported values for the language when hosted at Runestone are: <c>python</c>, <c>python3</c>, <c>c</c>, <c>cpp</c> (C++), <c>javascript</c>, <c>java</c>, <c>octave</c> (Matlab), <c>sql</c>, and <c>html</c>. When hosted on your own server, <c>python</c>, <c>javascript</c>, <c>sql</c>, and <c>html</c>, are supported with in-browser routines. So you do not need to configure <em>anything</em> server-side for this capability. See subsections of <xref ref="interactive-program-activecode"/> for details.</li>

   
   

   pretext/doc/guide/publisher/publication-file.xml

   Line 520 in 612c5fe

   <li><c>cpp</c> (C++, Runestone server only)</li>

   
   

   pretext/doc/guide/author/topics.xml

   Line 3729 in 612c5fe

   <table xml:id="table-program-interactive">

2. Schema updates only need to (should) be made to the XML file. The rest of the files are generated from it.

3. Rob likes a clean commit history. Doing my best to channel Rob, I would suggest...

• Drop the commits that turn on/off Runestone debugging
• Break up commits by what components they affect. The "Kotlin added throughout" should probably become 4 commits: one each for schema, runestone, common, and publisher variable files. (I could see leaving common and publisher variables lumped together.)
• Commit messages should start with Component: . See the commit history for examples.

Feel free to do an interactive rebase and force push to the PR with adjustments.

[rbeezer]

This looks good visually. One comment: the schema files are derived from a "literate programming" version in PreTeXt itself. Have a read here.

Don't do anything about it now. Generally, as a public service, I will rebuild those files as part of a merge and I can fix up the edits here already.

[dmusican]

Thanks for the help, @ascholerChemeketa and @rbeezer. I've updated the PR; let me know if I need to make more changes or if all is good.

[rbeezer]

Nice job on a well-formed pull request - especially on your first time out. Thanks.

I rotated a couple of commits, and fleshed out the schema changes. Otherwise merged as-is (but of course commits have changed, so your branch should be deleted and you can get caught up with a pull). Once tested on Runestone and with more examples, we can make any necessary updates.