Introduce linter to ensure KDoc is present

[BenHenning]

We need to ensure that KDocs are present on all non-private:

• Classes
• Values/fields
• Explicit constructors
• Companion objects
• Nested classes
• Enums
• Annotations
• Interfaces
• Extension functions

We should also make sure that the KDocs are properly formatted per the style guide. That is, the KDoc:

• Should start correctly (i.e. /**)
• End correctly (i.e.. */), and only have the ending on the same line as other text if the whole KDoc is single-line.
• Have correct spacing & prefixes for subsequent lines (i.e. *)
• Be immediately before the member being documented (no blank lines)
• Have no trailing spaces on any of the lines
• Have all lines fit within the 100 line character limit
• Only use valid at-tags (e.g. @param)
• Ensure there's exactly 1 blank line between the summary of the KDoc and the first at-param
• All at-params should be next to each other (no blank lines)
• At-param descriptions should start with lower case letters any only end in punctuation if they are multiple sentences
• KDocs should always have a summary fragment present that begins with a capital letter and ends with punctuation.

[adhiamboperes]

@BenHenning, we already have a KDOC validy check that checks most if not all of the requirements in this issue. Is something different needed? If not, then @deonwaju can review the kdoc validation script and verify that all the checks are present, then we can close this issue.

[BenHenning]

@adhiamboperes I think only the first list is addressed, right? The current KDoc checker is only for KDoc presence, not formatting validity. I've taken a stab at trying to fix this in the past, but I didn't make much progress on it. If I recall, our usage of the Kotlin compiler to determine KDoc presence involves checking for the presence of a documentation node in the parsed AST, and I think that node includes the raw document text for analysis. I do not remember what, if any, tokens are stripped by the compiler however (if it's not an exact copy including whitespace then we'll need to use its indexes to retrieve the comment directly from the source file since part of syntactical verification here is ensuring correct spacing of KDoc elements).