Fix typos and grammer in ADRs

Author: karlb

docs/adr/0008-connection-manager-prevents-fast-sync.rst

@@ -59,7 +59,7 @@ are code paths in the Raiden code base that are only required by the CM
 that caused bugs in the past. It is not clear if the CM in its current
 form helps us to achieve our goals and its behavior of doing
 transactions at times after joining a TN can make Raiden look bad at
-times of high gas costs. In other words, user is not made explicitly
+times of high gas costs. In other words, the user is not made explicitly
 aware that these channels incur gas costs and this problem is even more
 pronounced during times of high gas costs.
 

docs/adr/0010-refunds.rst

@@ -26,7 +26,7 @@ initiator. The initiator does not do anything on receiving the refund
 and the payment times out. This is the worst possible apporoach because:
 
 -  Refunds don’t provide any benefit
--  Doing refunds locks up additional funds until the payment times out
+-  Refunds lock up additional funds until the payment times out
 -  Refunds significantly increase complexity of the mediation code
 
 The light client has an incomplete and untested refund implementation,

docs/adr/0011-routing-with-token-swaps.rst

@@ -4,7 +4,7 @@ Routing With Built-In Token Swaps
 Use Case
 --------
 
-Buyer’s and sellers usually each have a preferred currency/token. When
+Buyers and sellers usually each have a preferred currency/token. When
 both parties prefer different tokens, one party has to accept dealing
 with a non-preferred token. In addition to being inconvenient, this can
 also require open a new channel, this making the payment slow and
@@ -18,7 +18,7 @@ Concept
 -------
 
 Node A wants to pay node B an amount of 10 T2 tokens, but A only has T1
-tokens. A requests a route from the PFS:
+tokens. Node A requests a route from the PFS:
 
 ::
 
@@ -52,5 +52,5 @@ Problems
    the same time.
 -  Behavior not clear for non-strict routing
 -  The route can fail due to changes in conversion rate. This can be
-   mitigated by adding some safety margin, but the increases the price
+   mitigated by adding some safety margin, but this increases the price
    for the sender.

docs/adr/0012-token-swaps.rst

@@ -33,7 +33,7 @@ Earn Fees by Providing Token Swaps
 
 In addition to providing normal mediation, mediators can also choose to
 act as an exchange between different token networks. The mediator will
-have to excplitly accept the legal risks and choose reasonable exchange
+have to explicitly accept the legal risks and choose reasonable exchange
 rates.
 
 Migrate Between Contract Versions
@@ -49,7 +49,7 @@ This can be mitigated by having some mediators open channels in the new
 contracts while keeping their old channels open. Then these mediators
 can mediate payments between the old and new networks.
 
-This will require support for multiple token network registries in the
+This will require support for multiple token network registries in
 the client. As a consequence, multiple token networks for the same token
 also have to be supported.
 
@@ -62,7 +62,7 @@ BTC, tokens on Ethereum, tokens on sidechains or other blockchains.
 
 Compared to the other use cases, this brings additional problems, since
 the PFS will not be able to find routes outside of Ethereum and we will
-have to coordinate with non-Raiden clients. As a consquence, this should
+have to coordinate with non-Raiden clients. As a consequence, this should
 be left out of the initial implementation. But we should keep it in
 mind, so that we don’t accidentally make it harder to add support for
 this in a later step.
@@ -109,7 +109,7 @@ will arise.
 Finding Routes Through Multiple Networks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Currently, the PFS handles each token network seperately, which prevents
+Currently, the PFS handles each token network separately, which prevents
 it from finding routes across different token networks. Implementing
 support for cross-TN-routes requires some changes to the data structures
 used in the PFS. Doing this naively will result in slow pathfinding,