Add nested dict template support; Add x-pattern

For cases where event schema specify `patternProperties` it would be nice
to give that pattern a "human-readable" form rather than a raw regex. This
is now supported by specifying `x-pattern` in the value part of the specified
pattern e.g. `patternProperties:{ "^.*":{ x-pattern: "$THING", ... } }`

Templating had limited record type descriptions limited to value primitives
e.g. `{string: integer}`. It now supports inspecting the values recursively
if the value is `object`.

Updated `m.receipt` to take both these points into account to make it read
better. Tweak receipt module text.

specification/modules/receipts.rst

@@ -6,8 +6,16 @@ have interacted with. For example, which events the user has read. For
 efficiency this is done as "up to" markers, i.e. marking a particular event
 as, say, ``read`` indicates the user has read all events *up to* that event.
 
-Client-Server API
-~~~~~~~~~~~~~~~~~
+Events
+------
+
+{{m_receipt_event}}
+
+Client behaviour
+----------------
+
+ - When clients should send receipts
+ - What clients should do when they receive these receipts
 
 Clients will receive receipts in the following format::
 
@@ -25,22 +33,6 @@ Clients will receive receipts in the following format::
         }
     }
 
-For example::
-
-    {
-        "type": "m.receipt",
-        "room_id": "!KpjVgQyZpzBwvMBsnT:matrix.org",
-        "content": {
-            "$1435641916114394fHBLK:matrix.org": {
-                "read": {
-                    "@erikj:jki.re": { "ts": 1436451550453 },
-                    ...
-                }
-            },
-            ...
-        }
-    }
-
 For efficiency, receipts are batched into one event per room. In the initialSync
 and v2 sync APIs the receipts are listed in a separate top level ``receipts``
 key. Each ``user_id``, ``receipt_type`` pair must be associated with only a
@@ -56,9 +48,8 @@ A client can update the markers for its user by issuing a request::
 Where the contents of the ``POST`` will be included in the content sent to
 other users. The server will automatically set the ``ts`` field.
 
-
-Server-Server API
-~~~~~~~~~~~~~~~~~
+Server behaviour
+----------------
 
 Receipts are sent across federation as EDUs with type ``m.receipt``. The
 format of the EDUs are::
@@ -75,3 +66,7 @@ format of the EDUs are::
 
 These are always sent as deltas to previously sent receipts.
 
+Security considerations
+-----------------------
+
+