Minor updates for the Coding Guide

[javagl]

The current CodingGuide contains a few recommendations that may have to be updated.

One specific point that was discussed as part of a recent PR is whether the Coding Guide should contain a recommendation like

Don't use Array.push.apply() for large arrays. Use addAllToArray or the [...spread] syntax instead
^{(Maybe with details about where the spread syntax should also be avoided...)}

I looked at the the Coding Guide, thinking about where something like this might be added. But there are two and a half issues with that:

1. There are some plainly outdated statements in the Coding Guide
2. Some recommendations there are obsolete, because they already are enforced with linting rules
   2½. The specific case of push.apply is already covered with a newly introduced linting rule

I think that very roughly speaking, the Coding Guide should not repeat things that are covered by the linter. (One could argue that it could explain why these rules exist, but that's a slippery slope, and might bloat it up to a point where nobody is reading it any more...)

Some preliminary points that I noticed and that might have to be updated accordingly, starting at the the Basic Code Construction section:

• "Cesium uses JavaScript's strict mode, so each module (file) contains "use strict"
  • That's as wrong as it can be. No file contains this anymore 🙂
• "To avoid type coercion..."
  • This is covered by eqeqeq
• "let and const variables have block-level scope"
  • This is covered by no-use-before-define
• "Modern language features may provide handy shortcuts and cleaner syntax, ..."
  • This is a bit vague. But the push.apply-to-[...spread] (with caveats) might fit here...
• "Do not use an unnecessary else block at the end of a function..."
  • This is covered by no-else-return

Some further (potential) updates are connected to open issues or pending PRs - just a quick summary:

• "Many Cesium functions take an options parameter..."
  • Some considerations to update this may be in Update Coding Guide with notes on destructuring assignment #12196
• "Don't use defaultValue if it could..."
  • TBD via the pending PR at remove defaultValue() and create DefaultValue namespace #12252
• "result Parameters and Scratch Variables ... Because result parameters aren't always required or returned,..."
  • I'm still wondering about how to make that more clear, About scratch variables and API consistency #12163 (comment)
• "Constructor Functions"
  • Some pending updates via Use ES6 "class" as module syntax #8359 (comment)
• Private Functions
  • I strongly disagree here. I always considered these file-scoped, free-floating functions to be obscure, and I'm sure that they now will make a clean transition to Use ES6 "class" as module syntax #8359 much, much harder...