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/00-statement-count-comparison.txt

@@ -0,0 +1,16 @@
+Same logical operation — load every order for a customer and read every item on
+every order — run against identical H2 data, counted by the same
+StatementLoggingDataSource, for two stacks.
+
+orders     items/ea   JPA (no fetch join)    Spring Data JDBC      
+1          1          2                      2                     
+1          5          2                      2                     
+5          1          6                      6                     
+5          5          6                      6                     
+20         3          21                     21                    
+
+JPA here uses plain findAll() + lazy .getItems() (scenario 02's shape); adding
+an @EntityGraph flattens the JPA column to a constant too (scenario 03). The
+point is not "JDBC beats JPA" in the abstract — it's that JDBC's default gives
+you the flattened shape for free, while JPA's default gives you the linear one,
+and the fix for JPA requires the reader to know it's needed.