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/rabbit-ordering.txt

@@ -0,0 +1,18 @@
+== RabbitMQ: FIFO per queue, per consumer ==
+
+one queue, one consumer, 12 messages
+  completion order : [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
+
+one queue, two consumers, prefetch 1, consumer-1 slower than consumer-2
+  completion order : [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 1, 12]
+  out-of-order steps: 1
+
+A queue is FIFO and a single consumer sees it that way. The moment a second
+consumer is added the broker hands the next message to whichever consumer
+is free, so the order in which work finishes is no longer the order in
+which it was published. There is no key: RabbitMQ has no notion of a
+partition to which related messages could be pinned. Ordering across
+related messages means one queue and one consumer, and therefore no
+horizontal scaling for that queue -- or a consistent-hash exchange, which
+is a plugin.
+