chore: fix spelling errors in multiple files (#34574)

* chore: fix spelling in .circleci

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in BUILD.gn

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in appveyor.yml

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in build

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in docs

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in lib

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in script

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in shell

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in spec

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in spec-main

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

docs/api/app.md

@@ -1381,7 +1381,7 @@ method returns false. If we fail to perform the copy, then this method will
 throw an error. The message in the error should be informative and tell
 you exactly what went wrong.
 
-By default, if an app of the same name as the one being moved exists in the Applications directory and is _not_ running, the existing app will be trashed and the active app moved into its place. If it _is_ running, the pre-existing running app will assume focus and the previously active app will quit itself. This behavior can be changed by providing the optional conflict handler, where the boolean returned by the handler determines whether or not the move conflict is resolved with default behavior.  i.e. returning `false` will ensure no further action is taken, returning `true` will result in the default behavior and the method continuing.
+By default, if an app of the same name as the one being moved exists in the Applications directory and is _not_ running, the existing app will be trashed and the active app moved into its place. If it _is_ running, the preexisting running app will assume focus and the previously active app will quit itself. This behavior can be changed by providing the optional conflict handler, where the boolean returned by the handler determines whether or not the move conflict is resolved with default behavior.  i.e. returning `false` will ensure no further action is taken, returning `true` will result in the default behavior and the method continuing.
 
 For example:
 

docs/api/session.md

@@ -713,7 +713,7 @@ To clear the handler, call `setDevicePermissionHandler(null)`.
 This handler can be used to provide default permissioning to devices without first calling for permission
 to devices (eg via `navigator.hid.requestDevice`).  If this handler is not defined, the default device
 permissions as granted through device selection (eg via `navigator.hid.requestDevice`) will be used.
-Additionally, the default behavior of Electron is to store granted device permision through the lifetime
+Additionally, the default behavior of Electron is to store granted device permission through the lifetime
 of the corresponding WebContents.  If longer term storage is needed, a developer can store granted device
 permissions (eg when handling the `select-hid-device` event) and then read from that storage with `setDevicePermissionHandler`.
 

docs/development/README.md

@@ -64,7 +64,7 @@ If you want to add a new API module to Electron, you'll want to look in [creatin
 
 Electron has a fully-fledged governance system that oversees activity in Electron and whose working groups are responsible for areas like APIs, releases, and upgrades to Electron's dependencies including Chromium and Node.js. Depending on how frequently and to what end you want to contribute, you may want to consider joining a working group.
 
-Details about each group and their reponsibilities can be found in the [governance repo](https://github.com/electron/governance).
+Details about each group and their responsibilities can be found in the [governance repo](https://github.com/electron/governance).
 
 ## Patches in Electron
 

docs/development/debugging.md

@@ -9,7 +9,7 @@ Some of the more common approaches are outlined below.
 
 Chromium contains logging macros which can aid debugging by printing information to console in C++ and Objective-C++.
 
-You might use this to print out variable values, function names, and line numbers, amonst other things.
+You might use this to print out variable values, function names, and line numbers, amongst other things.
 
 Some examples:
 
@@ -25,7 +25,7 @@ See [logging.h](https://chromium.googlesource.com/chromium/src/base/+/refs/heads
 
 ## Printing Stacktraces
 
-Chromium contains a helper to print stack traces to console without interrrupting the program.
+Chromium contains a helper to print stack traces to console without interrupting the program.
 
 ```cpp
 #include "base/debug/stack_trace.h"

docs/tutorial/devices.md

@@ -43,7 +43,7 @@ the WebHID API:
 * [`ses.setDevicePermissionHandler(handler)`](../api/session.md#sessetdevicepermissionhandlerhandler)
   can be used to provide default permissioning to devices without first calling
   for permission to devices via `navigator.hid.requestDevice`.  Additionally,
-  the default behavior of Electron is to store granted device permision through
+  the default behavior of Electron is to store granted device permission through
   the lifetime of the corresponding WebContents.  If longer term storage is
   needed, a developer can store granted device permissions (eg when handling
   the `select-hid-device` event) and then read from that storage with
@@ -92,7 +92,7 @@ There are several additional APIs for working with the Web Serial API:
 * [`ses.setDevicePermissionHandler(handler)`](../api/session.md#sessetdevicepermissionhandlerhandler)
   can be used to provide default permissioning to devices without first calling
   for permission to devices via `navigator.serial.requestPort`.  Additionally,
-  the default behavior of Electron is to store granted device permision through
+  the default behavior of Electron is to store granted device permission through
   the lifetime of the corresponding WebContents.  If longer term storage is
   needed, a developer can store granted device permissions (eg when handling
   the `select-serial-port` event) and then read from that storage with

docs/tutorial/electron-versioning.md

@@ -18,7 +18,7 @@ npm install --save-dev electron@latest
 
 There are several major changes from our 1.x strategy outlined below. Each change is intended to satisfy the needs and priorities of developers/maintainers and app developers.
 
-1. Strict use of the the [SemVer](#semver) spec
+1. Strict use of the [SemVer](#semver) spec
 2. Introduction of semver-compliant `-beta` tags
 3. Introduction of [conventional commit messages](https://conventionalcommits.org/)
 4. Well-defined stabilization branches