docs: Add Kotlin language standards (#33)

[jjhafer]

Document our Kotlin language standards for upcoming projects.

• Add kotlin.md and reference it in coding-standards.md.

[jjhafer]

@yokuze @velocitysystems Could you review this MR? Similar to the Swift standards, @velocitysystems can you consult with App Dev and come back with any suggestions on the Kotlin standards? And @yokuze, please verify that this matches what you expect in the repo?

[yokuze]

If you get any PR comments to address, then you could add trailing . to the bullet points in the first couple sections to match the last few sections, or vice-versa, but that's super minor and not worth your time unless you're already pushing.

Structure and content LGTM, but leaving the full content review up to @velocitysystems

[mnkyby78]

Sorry - this is my first review directly in Github. See my comments on the file itself.

[mnkyby78]

Should we allow for the omission of self explanatory comments? I think userId would be good candidate for a parameter that does not need a comment explaining what it is.

[mnkyby78]

Should we add a standard, perhaps under Whitespace, for closing parenthesis on functions that wrap lines? Like someFunctionWithAVeryLongName in the Line Length section - we want the closing parenthesis by itself on a new line, aligned left with the starting point

[mnkyby78]

Can we add a comment that we prefer simplicity, readability, and debuggability over clever solutions? We want future devs (or ourselves) to be able to quickly understand what's happening.

[yokuze]

It feels like this, and the Write comments to explain *why* code is written a certain way, not *what* the code does. above would be even better if they lived in the https://github.com/silvermine/silvermine-info/blob/master/coding-standards.md file since they're good principles that apply to all languages

[velocitysystems]

Looks good @jjhafer. Just a few thoughts when comparing with the official Kotlin coding conventions:

• Do we need to clarify bracing style e.g. always use braces for if/else, even for single-line blocks)?
• Do we need to include a comment about using explicit visibility modifiers? e.g. private, internal.
• Should we recommend using properties val / var over backing fields where possible?
• Should we encourage the use of Kotlin collections e.g. listOf, mutableListOf rather than Java collections? What about best-practice for mutability e.g. read-only by default?
• Should we add a section for imports e.g. avoidance of wildcard imports and organizing imports per Kotlin conventions?

[velocitysystems]

Comparing against our previous internal standards, just a few additional comments:

• Do we wish to include a copyright header in each file?
• Do we wish to recommend use of early return style vs. nested conditionals? (May be less Kotlin-specific)
• Should enums/enum values be documented?

[velocitysystems]

Suggestion: Add newline after closing curly brackets.