fix typos (VUnit#575)

* fix typos
* fix a typo
* update gitignore

.gitignore

@@ -9,6 +9,7 @@
 docs/_build
 docs/examples.rst
 docs/release_notes.rst
+.tox
 vunit/test/acceptance/*_out
 vunit/test/unit/test_report_output.txt
 env/

docs/cli.rst

@@ -186,7 +186,7 @@ Test Output Path Length Environment Variables
   tries to limit the length of the test output paths on Windows to
   avoid this limitation but still includes as much of the test name
   name as possible leaving a margin of 100 characters. VUnit however
-  cannot forsee user specifc test output file lengths and this
+  cannot forsee user specific test output file lengths and this
   environment variable can be set to minimize output path lengths on
   Windows. On other operating systems this limitation is not relevant.
 
@@ -212,7 +212,7 @@ using standard xUnit test parsers such as `Jenkins xUnit Plugin <http://wiki.jen
 Furthermore, VUnit can be easily executed in many different platforms (either operating systems or architectures), because it is written in Python, which is an interpreted language. However, besides the sources and VUnit, a `HDL compiler/simulator <https://en.wikipedia.org/wiki/List_of_HDL_simulators>`_ is required in order to run the tests. Due to performance, all the HDL simulators are written in compiled languages, which makes the releases platform specific. I.e., each simulator needs to be specifically compiled for a given architecture and operating system. This might represent a burden for the adoption of continuous integration in hardware development teams, as it falls into the category of dev ops.
 
 Nevertheless, thanks to the striking research about portable development environment solutions in the last decade, there are a bunch of alternatives to ease the path. The 'classic' approach is to use virtual machines with tools
-such as `VirtualBox <https://www.virtualbox.org/>`_, `QEMU <https://www.qemu.org/>`_ or `VMware <https://www.vmware.com>`_. This is still an option, but for most uses cases sharing complete system images is overkill. Here, `containerization or operating-system-level virtualization <https://en.wikipedia.org/wiki/Operating-system-level_virtualization>`_ comes into the game. Without going into technical details, containers are a kind of lightweight virtual machines, and the most known product that uses such a technology is `Docker <https://docker.com>`_. Indeed, products such as `Vagrant <https://www.vagrantup.com/>`_ are meant to simplify the usage of virtual machines and/or containers by providing a common (black) box approach. In the end, there are enough open/non-open and free/non-free solutions for each user/company to choose the one that best fits their needs. From the hardware designer point-of-view, we 'just' need a box (no matter the exact underlying technology) that includes VUnit and a simulator.
+such as `VirtualBox <https://www.virtualbox.org/>`_, `QEMU <https://www.qemu.org/>`_ or `VMware <https://www.vmware.com>`_. This is still an option, but for most use cases sharing complete system images is overkill. Here, `containerization or operating-system-level virtualization <https://en.wikipedia.org/wiki/Operating-system-level_virtualization>`_ comes into the game. Without going into technical details, containers are a kind of lightweight virtual machines, and the most known product that uses such a technology is `Docker <https://docker.com>`_. Indeed, products such as `Vagrant <https://www.vagrantup.com/>`_ are meant to simplify the usage of virtual machines and/or containers by providing a common (black) box approach. In the end, there are enough open/non-open and free/non-free solutions for each user/company to choose the one that best fits their needs. From the hardware designer point-of-view, we 'just' need a box (no matter the exact underlying technology) that includes VUnit and a simulator.
 
 Fortunately, contributors of project `GHDL <https://github.com/ghdl/ghdl>`_ provide ready-to-use docker images at `hub.docker.com/u/ghdl/dashboard <https://hub.docker.com/u/ghdl/dashboard/>`_. Some of these include not only GHDL but also VUnit:
 

docs/logging/user_guide.rst

@@ -260,8 +260,8 @@ message was produced.  There is also the ``check_log`` procedure which
 checks and consumes one log message from the list of recorded log calls to
 check a sequence of log messages.
 
-The ``mock`` procedures ensures that all future calls to the logger
-are recorded and not sent to a any log handler or cause simulation
+The ``mock`` procedures ensure that all future calls to the logger
+are recorded and not sent to a log handler or cause simulation
 abort. The ``unmock`` procedure restores the logger to its normal
 state.  The ``unmock`` call also checks that all recorded log messages
 have been checked by a corresponding ``check_log`` or