[Tracking] Code Spell-Checking Sprint

This is an approach suggestion for now, please feel free to comment.

Comments and variables in the source code still contain a LOT of typos or weird "spelling variations". I would suggest, we create a list of areas (doing it all at the same time is WAY too invasive of course) for tracking, and then put the sub issues derived from that out there up-for-grabs, after we've defined, how we want to tackle this. Here is a rule list as a first suggestion:

• Spellcheck/Formatting - don't do anything else: Sometimes you see a "potential quick change", like lambda-ing a property getter. Resist! 😸 Let's concentrate on spellchecking and reformatting, but not refactoring, no matter how tempting!
• (Obvious) Typos inside of comments: Correct typos indicated by VS, but do not correct overzealously, meaning: If how an indicated typo to solve is not immediate clear to you, just leave it. If it's an impactful change (like a typo which you're not sure to correct appears 20 times in a source file), rather create a new issue.
• Double-Space-Rule: Eliminate double-spaces behind a terminal punctuation, since this is a) a phased-out rule, which is no longer practiced, b) was US/English only and doesn't compute for an international audience and c) gets in the way, if it is applied accidentally inside of XML comments.
• Typos inside of local variables: Correct obvious typos in local variables, if the names are NOT abbreviated. Also correct accidentally used camelcAsenAming (camelCaseNaming), but do not introduce camel case naming, unless you can answer "What would @JeremyKuhne or @lonitra do" confidently: The reason is, that we have a lot of Win32 API calls in the repo, and those variables have a naming standard which consist of a lot weird abbreviations and in addition is often just not camelCase, and not even camelCaseIsh.
• Scope of other member items: NEVER change member names, which are protected, internal (Friend), virtual (Overridable) let alone public. If there is an obvious typo in such a member, please create a new issue so we can discuss, if we want to touch it (sometimes even changing an Internal member can be a breaking change, since ... you know ... Reflection...).

• Control.cs (Sub-issue/PR)
• Application.cs (Sub-issue/PR)
• DataGridView (Sub-issue/PR)
• [...to extend...] (Sub-issue/PR)

@Olina-Zhang, once we finalize this item and know what we want to do, we should take it over to the Designer repo, and - as suggestion - do the same?