Restrict comments to 100 characters

This is a rule I try enforce in PR but it's a bit of a hassle, this will
give a lint warning when it happens resulting in:

- Yellow underline in supported editors when eslint is installed
- Compilation will succeed since it's a warning not an error
- CI will fail as it does not allow lint warnings

Special case comments are ignored which includes @vt comments, table
comments and commented out code.

src/common/input/Keyboard.ts

@@ -380,7 +380,8 @@ export function evaluateKeyboardEvent(
           result.type = KeyboardResultType.SELECT_ALL;
         }
       } else if (ev.key && !ev.ctrlKey && !ev.altKey && !ev.metaKey && ev.keyCode >= 48 && ev.key.length === 1) {
-        // Include only keys that that result in a _single_ character; don't include num lock, volume up, etc.
+        // Include only keys that that result in a _single_ character; don't include num lock,
+        // volume up, etc.
         result.key = ev.key;
       } else if (ev.key && ev.ctrlKey) {
         if (ev.key === '_') { // ^_

src/common/input/TextDecoder.ts

@@ -28,8 +28,8 @@ export function utf32ToString(data: Uint32Array, start: number = 0, end: number
   for (let i = start; i < end; ++i) {
     let codepoint = data[i];
     if (codepoint > 0xFFFF) {
-      // JS strings are encoded as UTF16, thus a non BMP codepoint gets converted into a surrogate pair
-      // conversion rules:
+      // JS strings are encoded as UTF16, thus a non BMP codepoint gets converted into a surrogate
+      // pair conversion rules:
       //  - subtract 0x10000 from code point, leaving a 20 bit number
       //  - add high 10 bits to 0xD800  --> first surrogate
       //  - add low 10 bits to 0xDC00   --> second surrogate

src/common/input/WriteBuffer.ts

@@ -181,9 +181,10 @@ export class WriteBuffer extends Disposable {
 
         /**
          * If a promise takes long to resolve, we should schedule continuation behind setTimeout.
-         * This might already be too late, if our .then enters really late (executor + prev thens took very long).
-         * This cannot be solved here for the handler itself (it is the handlers responsibility to slice hard work),
-         * but we can at least schedule a screen update as we gain control.
+         * This might already be too late, if our .then enters really late (executor + prev thens
+         * took very long). This cannot be solved here for the handler itself (it is the handlers
+         * responsibility to slice hard work), but we can at least schedule a screen update as we
+         * gain control.
          */
         const continuation: (r: boolean) => void = (r: boolean) => Date.now() - startTime >= WRITE_TIMEOUT_MS
           ? setTimeout(() => this._innerWrite(0, r))