Extend multi-row INSERT (addRow) to execute() and loop-friendly call shapes (#1825)

[zio0911]

Summary

Closes #1825. Two related improvements to multi-row INSERT support via addRow() on JPAInsertClause / HibernateInsertClause:

1. Multi-row execution without returning keys — a plain execute() now emits a single native INSERT INTO t (...) VALUES (..),(..),... when rows were accumulated via addRow(), returning the affected row count. Previously this only worked through executeWithKeys(...), forcing callers to use a key-returning method even when keys were not needed.
2. Loop-friendly multi-row call shape — addRow() now captures effective column paths on its first call. execute() (multi-row path) and executeWithKeys(...) fall back to those captured paths when the current-state inserts/columns are empty. This makes the natural for-loop with set(...).addRow() at the end of every iteration work, without a "first row" flag and without keeping the last row in the buffer.

Call site shapes that now work

// set()-style, trailing addRow(), no keys needed
var insert = queryFactory.insert(entity);
for (var r : rows) {
  insert
      .set(entity.a, r.a())
      .set(entity.b, r.b())
      .addRow();
}
long count = insert.execute();

// columns()/values()-style, trailing addRow(), keys returned
var keys = queryFactory.insert(entity)
    .columns(entity.a, entity.b)
    .values(1, "x").addRow()
    .values(2, "y").addRow()
    .executeWithKeys(entity.id);

Behavioral changes

• JPAInsertClause.execute() / HibernateInsertClause.execute():
  • If rows (accumulated via addRow()) is non-empty and no subQuery is set, emits a single native multi-row INSERT INTO t (...) VALUES (..),(..),... and returns the affected row count.
  • All other cases (single-row plain INSERTs, INSERT ... SELECT, template-value INSERTs already routed through native) keep their existing path.
• addRow():
  • Captures effective column paths once, on its first call. Executors use those captured paths as fallback when inserts/columns are both empty (i.e. the trailing iteration was also closed with addRow()).
• JpaInsertNativeHelper.requireSqlModule() (added): native insert paths depend on the optional querydsl-sql module; guards them with an actionable IllegalStateException instead of an opaque NoClassDefFoundError when querydsl-sql is absent from the classpath.
• addRow() Javadoc clarified: builds a single multi-row VALUES statement, not JDBC batching.

Out of scope / clarifications

• addRow() builds a single SQL statement with multiple VALUES tuples. It is not JDBC batching (PreparedStatement.addBatch() / executeBatch()).
• Single-row inserts without addRow() are unchanged.
• INSERT ... SELECT (select(SubQueryExpression)) is unchanged and still rejects addRow().

Test plan

• New unit/integration tests in JPAExecuteWithKeyTest and HibernateExecuteWithKeyTest covering both new shapes:
  • execute_multi_row_set_style_with_trailing_addRow — set() + trailing addRow() + execute() (no keys)
  • executeWithKeys_multi_row_set_style_with_trailing_addRow — same shape + key return
  • execute_multi_row_without_keys_inserts_all_rows — columns()/values() + addRow + execute()
  • execute_multi_row_in_a_loop_with_trailing_addRow — loop-friendly form with columns()/values()
• ./mvnw -pl querydsl-libraries/querydsl-jpa -Pno-databases test — 414 tests pass, 0 failures.