Clarify terminology around aggregations (#1424)

I've done my best to remove the word "bundle", because I feel like it causes
more confusion than it provides. Instead I have favoured "aggregated child
events" which I think is clearer.

Some general clarification around these parts of the spec.

data/api/client-server/threads_list.yaml

@@ -30,10 +30,12 @@ paths:
   "/rooms/{roomId}/threads":
     get:
       x-addedInMatrixVersion: "1.4"
-      summary: Retrieve a list of threads in a room, with optional filters.
+      summary: Fetches a list of the threads in a room.
       description: |-
-        Paginates over the thread roots in a room, ordered by the `latest_event` of each thread root
-        in its bundle.
+        This API is used to paginate through the list of the thread roots in a given room. 
+        
+        Optionally, the returned list may be filtered according to whether the requesting
+        user has participated in the thread.
       operationId: getThreadRoots
       security:
         - accessToken: []
@@ -85,8 +87,8 @@ paths:
               chunk:
                 type: array
                 description: |-
-                  The thread roots, ordered by the `latest_event` in each event's aggregation bundle. All events
-                  returned include bundled [aggregations](/client-server-api/#aggregations).
+                  The thread roots, ordered by the `latest_event` in each event's aggregated children. All events
+                  returned include bundled [aggregations](/client-server-api/#aggregations-of-child-events).
 
                   If the thread root event was sent by an [ignored user](/client-server-api/#ignoring-users), the
                   event is returned redacted to the caller. This is to simulate the same behaviour of a client doing