docs: fixed typos and grammatical errors (#41058)

* docs: fixed typos

Co-authored-by: Villy-P <[email protected]>

* Update docs/tutorial/performance.md

Co-authored-by: Keeley Hammond <[email protected]>

Co-authored-by: Valerius Petrini <[email protected]>

* Update performance.md

Co-authored-by: Valerius Petrini <[email protected]>

---------

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Villy-P <[email protected]>
Co-authored-by: Valerius Petrini <[email protected]>

docs/tutorial/devices.md

@@ -33,7 +33,7 @@ clicked.
 ## WebHID API
 
 The [WebHID API](https://web.dev/hid/) can be used to access HID devices such
-as keyboards and gamepads.  Electron provides several APIs for working with
+as keyboards and gamepads. Electron provides several APIs for working with
 the WebHID API:
 
 * The [`select-hid-device` event on the Session](../api/session.md#event-select-hid-device)

docs/tutorial/in-app-purchases.md

@@ -107,7 +107,7 @@ if (!inAppPurchase.canMakePayments()) {
 inAppPurchase.getProducts(PRODUCT_IDS).then(products => {
   // Check the parameters.
   if (!Array.isArray(products) || products.length <= 0) {
-    console.log('Unable to retrieve the product informations.')
+    console.log('Unable to retrieve the product information.')
     return
   }
 

docs/tutorial/performance.md

@@ -24,7 +24,7 @@ careful to understand that the term "performance" means different things for
 a Node.js backend than it does for an application running on a client.
 
 This list is provided for your convenience – and is, much like our
-[security checklist][security] – not meant to exhaustive. It is probably possible
+[security checklist][security] – not meant to be exhaustive. It is probably possible
 to build a slow Electron app that follows all the steps outlined below. Electron
 is a powerful development platform that enables you, the developer, to do more
 or less whatever you want. All that freedom means that performance is largely
@@ -83,7 +83,7 @@ is not in fact the leanest or smallest one available.
 
 The reasoning behind this recommendation is best illustrated with a real-world
 example. During the early days of Electron, reliable detection of network
-connectivity was a problem, resulting many apps to use a module that exposed a
+connectivity was a problem, resulting in many apps using a module that exposed a
 simple `isOnline()` method.
 
 That module detected your network connectivity by attempting to reach out to a

docs/tutorial/process-model.md

@@ -83,7 +83,7 @@ terminated as well.
 
 The main process also controls your application's lifecycle through Electron's
 [`app`][app] module. This module provides a large set of events and methods
-that you can use to add custom application behaviour (for instance, programmatically
+that you can use to add custom application behavior (for instance, programmatically
 quitting your application, modifying the application dock, or showing an About panel).
 
 As a practical example, the app shown in the [quick start guide][quick-start-lifecycle]

docs/tutorial/sandbox.md

@@ -17,7 +17,7 @@ further configuration. If you want to disable the sandbox for a process, see the
 [Disabling the sandbox for a single process](#disabling-the-sandbox-for-a-single-process)
 section.
 
-## Sandbox behaviour in Electron
+## Sandbox behavior in Electron
 
 Sandboxed processes in Electron behave _mostly_ in the same way as Chromium's do, but
 Electron has a few additional concepts to consider because it interfaces with Node.js.