Refactor code generation to produce Scala version-specific code

Major structural changes:
- Move away from generating code in shared Scala 2.13/3 subset
- Generate separate test code for Scala 2.13 (with -Xsource:3) and Scala 3.7
- Split Scala versions: LTS 3.3 for generator, newest 3.7 for test projects
- Create version-specific generated directories (generated-and-checked-in-2.13 and generated-and-checked-in-3)

Build system updates:
- Configure separate source directories per Scala version in bleep.yaml
- Update .scalafmt.conf with rewrite rules for Scala 3 syntax
- Adjust script configurations for multi-version generation

Code generation improvements:
- Fix all implicit parameter warnings for Scala 3.7 by using dialect.usingCall
- Replace hardcoded 'using' with dialect-aware implicit/using syntax
- Ensure proper implicit parameter handling across all db/json libraries
- Generate idiomatic code for each Scala version rather than lowest common denominator

This guarantees compilation on newest Scala 3 releases while maintaining backwards compatibility

Make update method return Option[Row] instead of Boolean for all data…

…base libraries (#139)

* Make update method return Option[Row] instead of Boolean for all database libraries

- Changed update method signature to return Option[Row] using PostgreSQL RETURNING clause
- Applied changes to all three database libraries:
  - Anorm: Uses executeInsert with singleOpt parser
  - Doobie: Uses query with option combinator
  - ZIO-JDBC: Uses query with selectOne
- Updated all tests to verify the returned Option contains expected values
- Updated mock implementations to return the row instead of boolean

This provides better feedback about what was actually updated and enables
verification that the update was applied correctly.

* Fix test warnings and update documentation for Option[Row] return type

bleep 0.0.13 (#155)

Generate update set on conflict for upserts (#145)

When upserting to tables with only key columns, typo would generate `do nothing`
as a conflict resolution. This has the disadvantage of making the query not
execute the `returning` part, which meant that in cases where an upsert was
executed targeting a single row, no rows would return and the generated code
would cause an error.

As a workaround, we generate `update set k = excluded.k` for an arbitrary key
column k instead. This causes the `returning` part of the query to run but
shouldn't change the value of the row as typo sees it.

- Add failing test case for upserting on an existing row
- Make the test case work by generating `update set` instead of `do nothing`

TestInsert: Don't wrap inherited ID types (#143)

* add test case for #142

* don't wrap inherited IDs (closes #142)

* fmt

bump to bleep 0.0.7

DSL: Add spaces after column names (fixes #129) (#132)

* add test for #129

* force space after column names (fixes #129)

Port typo module to 2.12 (Towards #52) (#127)

This reverts part of #92, but only for the code generation code. the generated code will not work for 2.12

Add `upsertStreaming` and `upsertBatch` (fix #115) (#117)

* Add `upsertStreaming` (fix #115)

* Add `upsertBatch` repo method.

caveats:
- anorm didn't support returning rows for batch queries, so it's monkey-patched in into the `anorm` package
- zio-jdbc cannot express batch updates at all. For this reason it was necessary to add support for not implementing a repo method for a dblib.

* fix upsert for tables where all columns appear in id

always keep domains

have to do this because of the logic in testinsert/insertdomains.

When we have more structured scala types we can discover which ones are really in use, but for now if a domain is embedded in a primary key we wont find it.