docs: Fix a few typos (#4957)

There are small typos in:
- docs/api/selector.md
- docs/api/storage_manager.md
- docs/modules/Blocks.md
- docs/modules/Components.md
- docs/modules/I18n.md
- docs/modules/Storage.md
- docs/modules/Traits.md

Fixes:
- Should read `argument` rather than `argumnet`.
- Should read `with` rather than `wiht`.
- Should read `redundant` rather than `redundent`.
- Should read `propagation` rather than `propogation`.
- Should read `performances` rather than `perfomances`.
- Should read `implementation` rather than `implemenation`.
- Should read `contributors` rather than `contributos`.
- Should read `attached` rather than `attacched`.

Signed-off-by: Tim Gates <tim.gates@iress.com>

docs/api/selector.md

@@ -11,7 +11,7 @@
 *   `type` **[Number][2]?** Type of the selector. 1 (class) | 2 (id)
 *   `active` **[Boolean][3]?** If not active, it's not selectable by the Style Manager.
 *   `private` **[Boolean][3]?** If true, it can't be seen by the Style Manager, but it will be rendered in the canvas and in export code.
-*   `protected` **[Boolean][3]?** If true, it can't be removed from the attacched component.
+*   `protected` **[Boolean][3]?** If true, it can't be removed from the attached component.
 
 ### toString
 

docs/api/storage_manager.md

@@ -26,10 +26,10 @@ storageManager.add(...);
 ## Available Events
 
 *   `storage:start` - Before the storage request is started
-*   `storage:start:store` - Before the store request. The object to store is passed as an argumnet (which you can edit)
-*   `storage:start:load` - Before the load request. Items to load are passed as an argumnet (which you can edit)
-*   `storage:load` - Triggered when something was loaded from the storage, loaded object passed as an argumnet
-*   `storage:store` - Triggered when something is stored to the storage, stored object passed as an argumnet
+*   `storage:start:store` - Before the store request. The object to store is passed as an argument (which you can edit)
+*   `storage:start:load` - Before the load request. Items to load are passed as an argument (which you can edit)
+*   `storage:load` - Triggered when something was loaded from the storage, loaded object passed as an argument
+*   `storage:store` - Triggered when something is stored to the storage, stored object passed as an argument
 *   `storage:end` - After the storage request is ended
 *   `storage:end:store` - After the store request
 *   `storage:end:load` - After the load request

docs/modules/Blocks.md

@@ -79,7 +79,7 @@ const editor = grapesjs.init({
 The key of connecting blocks to components is the `block.content` property and what we passed in the example above is the [Component Definition]. This is the component-oriented way to create blocks and this is how we highly recommend the creation of your blocks.
 
 ### Component-oriented
-The `content` can accept different formats, like an HTML string (which will be parsed and converted to components), but the component-oriented approach is the most precise as you can keep the control of your each dropped block in the canvas. Another advice is to keep your blocks' [Component Definition] as light as possible, if you're defining a lot of redundent properties, probably it makes sense to create another dedicated component, this might reduce the size of your project JSON file. Here an example:
+The `content` can accept different formats, like an HTML string (which will be parsed and converted to components), but the component-oriented approach is the most precise as you can keep the control of your each dropped block in the canvas. Another advice is to keep your blocks' [Component Definition] as light as possible, if you're defining a lot of redundant properties, probably it makes sense to create another dedicated component, this might reduce the size of your project JSON file. Here an example:
 
 ```js
 // Your components

docs/modules/Components.md

@@ -869,7 +869,7 @@ If you want to know how to create Components with javascript attached (eg. count
 
 ### JSX syntax
 
-If you're importing big chunks of HTML string into the editor (eg. defined via Blocks) JSX might be a great compromise between perfomances and code readibility as it allows you to skip the parsing and the component recognition steps by keeping the HTML syntax.
+If you're importing big chunks of HTML string into the editor (eg. defined via Blocks) JSX might be a great compromise between performances and code readibility as it allows you to skip the parsing and the component recognition steps by keeping the HTML syntax.
 By default, GrapesJS understands objects generated from React JSX preset, so, if you're working in the React app probably you're already using JSX and you don't need to do anything else, your environment is already configured to parse JSX in javascript files.
 
 So, instead of writing this:

docs/modules/I18n.md

@@ -143,7 +143,7 @@ We need to find the way to update the UI
 If you want to support GrapesJS by adding a new language to our repository all you need to do is to follow steps below:
 
 1. First of all, be sure to check the language file in [`src/i18n/locale`](https://github.com/GrapesJS/grapesjs/blob/master/src/i18n/locale) doesn't exist already
-1. [Open a new issue](https://github.com/GrapesJS/grapesjs/issues/new?title=XX%20Language%20support) to avoid overlap with other contributos. To be sure, check also no one else has opened already an issue for the same language
+1. [Open a new issue](https://github.com/GrapesJS/grapesjs/issues/new?title=XX%20Language%20support) to avoid overlap with other contributors. To be sure, check also no one else has opened already an issue for the same language
 1. Start a new branch from `dev`
 1. Copy (in the same folder) and rename the [`en` locale file] to the name of your language of choice (be sure to be compliant to [ISO 639-1])
 1. Now you can start translating strings

docs/modules/Storage.md

@@ -287,7 +287,7 @@ Storage.add('remote-local', {
 
 You can also replace already defined storages with other implementations by passing the same storage type in the `Storage.add` method. You can switch, for example, the default `local`, which relies on [localStorage API], with something more scalable like [IndexedDB  API].
 
-It might also be possible that you're already using some HTTP client library (eg. [axios](https://github.com/axios/axios)) which handles for you all the necessary HTTP headers in your application (CSRF token, session data, etc.), so you can simply replace the default `remote` storage wiht your implemenation of choice without caring about the default configurations.
+It might also be possible that you're already using some HTTP client library (eg. [axios](https://github.com/axios/axios)) which handles for you all the necessary HTTP headers in your application (CSRF token, session data, etc.), so you can simply replace the default `remote` storage with your implementation of choice without caring about the default configurations.
 
 ```js
 editor.Storage.add('remote', {

docs/modules/Traits.md

@@ -523,7 +523,7 @@ The integration with external components is possible by following these simple c
 
 1. **Component rendering**: `new Vue({ render: ...`<br/>
   Depends on the framework, for example, in React it should be `ReactDOM.render(element, ...`
-1. **Change propogation**: `sliderInst.$on('change', ev => this.onChange(ev))`<br/>
+1. **Change propagation**: `sliderInst.$on('change', ev => this.onChange(ev))`<br/>
   The framework should have a mechanism to subscribe to changes and the component [should expose that change](https://nightcatsama.github.io/vue-slider-component/#/api/events)<br/>
   We've also used `onChange` method which comes handy when you need to trigger manually the `onEvent` event (you should never call directly `onEvent` method, but only via `onChange` when you need)
 1. **Property getters/setters**: [`sliderInst.getValue()`](https://nightcatsama.github.io/vue-slider-component/#/api/methods?hash=getvalue)/ [`sliderInst.setValue(value)`](https://nightcatsama.github.io/vue-slider-component/#/api/methods?hash=setvaluevalue)<br/>