#1730 - Fix for wrong JDBC batch sorting / ordering

This is a bit of a refactor that simplifies the ordering of
batch execution (BatchedBeanHolder ordering). In short we
batch by bean type and depth (rather than just type).

This means that there are some cases we are not optimal
(where we could batch by bean type in different depths)
but that is expected to be rare and problematic for
hierarchies of the same type.

src/test/java/org/tests/cascade/TestMultiCascadeBatch.java

@@ -28,6 +28,7 @@ public class TestMultiCascadeBatch extends BaseTestCase {
 
   @Test
   public void testMultipleCascadeInsideTransaction() {
+
     final Site mainSite = new Site();
     mainSite.setName("mainSite");
     Ebean.save(mainSite);

src/test/java/org/tests/model/basic/xtra/TestInsertBatchThenFlushThenUpdate.java

@@ -38,7 +38,7 @@ public class TestInsertBatchThenFlushThenUpdate extends BaseTestCase {
       Ebean.save(parent);
 
       // nothing flushed yet
-      assertEquals(0, LoggedSqlCollector.start().size());
+      assertThat(LoggedSqlCollector.start()).isEmpty();
 
       txn.flushBatch();
 
@@ -49,14 +49,14 @@ public class TestInsertBatchThenFlushThenUpdate extends BaseTestCase {
       Ebean.save(parent);
 
       // nothing flushed yet
-      assertEquals(0, LoggedSqlCollector.start().size());
+      assertThat(LoggedSqlCollector.start()).isEmpty();
 
       Ebean.commitTransaction();
 
       // insert statements for EdExtendedParent
       List<String> loggedSql2 = LoggedSqlCollector.start();
-      assertEquals(2, loggedSql2.size());
-      assertTrue(loggedSql2.get(0).contains(" update td_parent "));
+      assertThat(loggedSql2).hasSize(2);
+      assertThat(loggedSql2.get(0)).contains(" update td_parent ");
     }
   }