Add jdbc-vs-jpa module: Spring Data JDBC vs JPA on a shared Order aggregate

Same Customer/Order/OrderItem domain modelled with Hibernate/Spring Data JPA and
Spring Data JDBC side by side, both running through a shared StatementLoggingDataSource
so SQL-statement counts are directly comparable. 11 tests, 11 captured transcripts,
6 doc chapters. Companion repo for the ankurm.com article on when to drop the ORM.

jdbc-vs-jpa/docs/output/06-fixed-cost-load.txt

@@ -0,0 +1,10 @@
+Scenario: findById on an order with 1 item, then on an order with 5 items — no
+@EntityGraph, no fetch annotation, this is the default and only behaviour.
+
+statements for 1-item order:  2   (items loaded: 1)
+statements for 5-item order:  2   (items loaded: 5)
+
+Both counts are the same. There is no lazy vs eager choice to make because
+Spring Data JDBC has no lazy loading: findById always returns the complete
+aggregate. Compare to JpaBehaviorTest scenario 02, where the naive path is O(N)
+in the number of orders touched, not items.