fix: EXPOSED-57 BatchInsertStatement can't be used with MySQL upsert

[bog-walk]

Most DB return the affected-row value 1 following an upsert statement, with the exception of MySQL, MariaDB, and their related H2 modes. These DB can return multiple values, which may change depending on whether a user flag is set:

... the affected-rows value per row is 1 if the row is inserted as a new row, 2 if an existing row is updated, and 0 if an existing row is set to its current values. If you specify the CLIENT_FOUND_ROWS flag ... the affected-rows value is 1 (not 0) if an existing row is set to its current values.

InsertStatement.insertedCount used to be calculated as a count of returned values, which gave inaccurate results if used with batchInsert(ignore = true). e.g. Inserting 2 rows and ignoring 1 returned a value of 3 instead of a more accurate value of 2. This was fixed by using a sum in PR#1641.

However, using a sum means that an assert() in InsertStatement.processResults() would throw whenever an upsert is performed, because the sum of affected-row values might not match the amount of generated auto-increment keys.

In addition to returning 3 possible values, these DB also return generated keys differently:

• [MySQL] -> no keys generated for updates with no data change and double keys generated for updates with new data.
• [MariaDB] -> no keys generated for updates with no data change and single keys generated for updates with new data.
• [H2 modes] -> no option for user flag and no keys generated for any updates (only for inserts).

Given all that, a flag, supportsTernaryAffectedRowValues, has been added to the default dialects, to be used as a condition that prevents AssertionError in the event a key-inserted mismatch occurs for a dialect that returns multiple values.

Refactor:

• Test util excludingH2Version1 updated to use a pre-existing H2Dialect function, isSecondVersion.