Add the broker-comparison module

Kafka, RabbitMQ and Pulsar measured side by side on ordering, replay and
consumer scaling by driving the three client libraries directly, plus an
operational-footprint measurement of each broker's own distribution.

Nine tests, three brokers started without Docker, and every number in the
documentation regenerated by scripts/run-all.sh.

broker-comparison/docs/output/pulsar-ordering.txt

@@ -0,0 +1,24 @@
+== Pulsar: the subscription type decides ==
+
+12 messages, keys A/B/C, values 1..12 in order, two consumers per
+subscription, receiverQueueSize 1 so the first consumer cannot take the
+whole backlog.
+
+Shared subscription, which consumers saw each key:
+  A -> [consumer-1, consumer-2]
+  B -> [consumer-1, consumer-2]
+  C -> [consumer-1, consumer-2]
+
+Key_Shared subscription, which consumers saw each key:
+  A -> [consumer-1]
+  B -> [consumer-1]
+  C -> [consumer-1]
+
+A Shared subscription round-robins individual messages, so messages with
+the same key end up on different consumers and can be processed at the
+same time: there is no per-key order left to speak of. Key_Shared hashes
+the key to one consumer, which is Kafka's guarantee -- except that the
+assignment belongs to the subscription and is recomputed as consumers come
+and go, rather than being fixed by a partition count chosen when the topic
+was created.
+