docs: fix a few simple typos

There are small typos in:
- docs/source/articles/creatingagameengineplugin.rst
- docs/source/articles/whatsinareplay.rst
- docs/source/tutorials/prettyprinter.rst
- examples/sc2autosave.py
- sc2reader/engine/engine.py
- sc2reader/events/game.py
- sc2reader/objects.py
- sc2reader/resources.py

Fixes:
- Should read `aggregated` rather than `aggrated`.
- Should read `account` rather than `acount`.
- Should read `versatile` rather than `versitile`.
- Should read `unnecessary` rather than `unncessary`.
- Should read `targeting` rather than `targetting`.
- Should read `substitution` rather than `substition`.
- Should read `requirements` rather than `requirments`.

Closes #145

docs/source/articles/creatingagameengineplugin.rst

@@ -52,7 +52,7 @@ Plugins may also handle special ``InitGame`` and ``EndGame`` events. These handl
   replay state necessary.
 
 * handleEndGame - is called after all events have been processed and
-  can be used to perform post processing on aggrated data or clean up
+  can be used to perform post processing on aggregated data or clean up
   intermediate data caches.
 
 Message Passing

docs/source/articles/whatsinareplay.rst

@@ -35,7 +35,7 @@ The last file provides a record of important events from the game.
 
 * replay.tracker.events - Records important game events and game state updates.
 
-This file was introduced in 2.0.4 and is unncessary for the Starcraft II to reproduce the game. Instead, it records interesting game events and game state for community developers to use when analyzing replays.
+This file was introduced in 2.0.4 and is unnecessary for the Starcraft II to reproduce the game. Instead, it records interesting game events and game state for community developers to use when analyzing replays.
 
 
 What isn't in a replay?

docs/source/tutorials/prettyprinter.rst

@@ -182,7 +182,7 @@ So lets put it all together into the final script, ``prettyPrinter.py``:
 Making Improvements
 ---------------------------
 
-So our script works fine for single files, but what if you want to handle  multiple files or directories? sc2reader provides two functions for loading replays: :meth:`~sc2reader.factories.SC2Factory.load_replay` and :meth:`~sc2reader.factories.SC2Factory.load_replays` which return a single replay and  a list respectively. :meth:`~sc2reader.factories.SC2Factory.load_replay` was used above for convenience but :meth:`~sc2reader.factories.SC2Factory.load_replays` is much more versitile. Here's the difference:
+So our script works fine for single files, but what if you want to handle  multiple files or directories? sc2reader provides two functions for loading replays: :meth:`~sc2reader.factories.SC2Factory.load_replay` and :meth:`~sc2reader.factories.SC2Factory.load_replays` which return a single replay and  a list respectively. :meth:`~sc2reader.factories.SC2Factory.load_replay` was used above for convenience but :meth:`~sc2reader.factories.SC2Factory.load_replays` is much more versatile. Here's the difference:
 
 * :meth:`~sc2reader.factories.SC2Factory.load_replay`: accepts a file path or an opened file object.
 * :meth:`~sc2reader.factories.SC2Factory.load_replays`: accepts a collection of opened file objects or file paths. Can also accept a single path to a directory; files will be pulled from the directory using :func:`~sc2reader.utils.get_files` and the given options.

examples/sc2autosave.py

@@ -37,7 +37,7 @@
 --------------------
 
 The --rename option allows you to specify a renaming format string. The string
-is constructed the pythonic (3.0) way with {:field} indicating the substition
+is constructed the pythonic (3.0) way with {:field} indicating the substitution
 of a field. The forward slash (/) is a special character here which terminates
 a folder name and allows for organization into subdirectories. All other string
 characters form the template into which the fields are inserted.

sc2reader/engine/engine.py

@@ -68,7 +68,7 @@ def handleEventName(self, event, replay)
             replay state necessary.
 
           * handleEndGame - is called after all events have been processed and
-            can be used to perform post processing on aggrated data or clean up
+            can be used to perform post processing on aggregated data or clean up
             intermediate data caches.
 
         Event handlers can choose to ``yield`` additional events which will be injected

sc2reader/events/game.py

@@ -351,7 +351,7 @@ class SelectionEvent(GameEvent):
     player is updated. Unlike other game events, these events can also be
     generated by non-player actions like unit deaths or transformations.
 
-    Starting in Starcraft 2.0.0, selection events targetting control group
+    Starting in Starcraft 2.0.0, selection events targeting control group
     buffers are also generated when control group selections are modified
     by non-player actions. When a player action updates a control group
     a :class:`ControlGroupEvent` is generated.

sc2reader/objects.py

@@ -129,7 +129,7 @@ def __init__(self, sid, slot_data):
         #: The Battle.net subregion the entity is registered to
         self.subregion = int(parts[2])
 
-        #: The Battle.net acount identifier. Used to construct the
+        #: The Battle.net account identifier. Used to construct the
         #: bnet profile url. This value can be zero for games
         #: played offline when a user was not logged in to battle.net.
         self.toon_id = int(parts[3])
@@ -200,7 +200,7 @@ def __init__(self, pid, detail_data, attribute_data):
         #: The Battle.net subregion the entity is registered to
         self.subregion = detail_data['bnet']['subregion']
 
-        #: The Battle.net acount identifier. Used to construct the
+        #: The Battle.net account identifier. Used to construct the
         #: bnet profile url. This value can be zero for games
         #: played offline when a user was not logged in to battle.net.
         self.toon_id = detail_data['bnet']['uid']

sc2reader/resources.py

@@ -923,7 +923,7 @@ def use_property(prop, player=None):
 
                 # Lobby properties can require on player properties.
                 # How does this work? I assume that one player satisfying the
-                # property requirments is sufficient
+                # property requirements is sufficient
                 if requirement.is_lobby:
                     values = [setting]
                 else: