feat(typedsql): support column & param nullability

[Weakky]

Overview

Closes https://github.com/prisma/team-orm/issues/1258

• Infer column and param nullability when possible, for Postgres, MySQL and SQLite.
• Allow overriding nullability for params & columns
  • For params: with -- @param $1:alias? (param alias must be suffixed with ?)
  • For columns: with select id as "id?" from table(column alias must be suffixed with ?)
• On Postgres, selected expressions that lead to ?column? as column name are forbidden and require an alias to be specified. This avoids clashing with the ? suffix heuristic to override nullability.

Included but not related to nullability:

• Enum names can be referenced in -- @param {Type} magic docs to override inferred type
• When SQLite does not infer a column type and we fallback to SQLx, we always treat integers as i64's

[codspeed-hq]

CodSpeed Performance Report

Merging #4979 will not alter performance

_{Comparing feat/typed-sql-nullability (aad0c68) with main (b5beb48)}

Summary

✅ 11 untouched benchmarks

[github-actions]

WASM Query Engine file Size

Engine	This PR	Base branch	Diff
Postgres	2.063MiB	2.061MiB	2.001KiB
Postgres (gzip)	823.739KiB	822.827KiB	934.000B
Mysql	2.033MiB	2.032MiB	1.167KiB
Mysql (gzip)	811.288KiB	810.526KiB	780.000B
Sqlite	1.924MiB	1.926MiB	-2.240KiB
Sqlite (gzip)	768.297KiB	769.614KiB	-1.317KiB

[Weakky]

We don't need nullable to be an Option.

[Weakky]

I ended up keeping it as an Option. The rationale is that I'd like to keep the parser unopinionated. If it finds a ?, it's Some(true). Else, it's None. It's up to the introspect_sql implementation to give semantic value to this information, and .unwrap_or(default) with the correct default. I did simplify things by always returning None when ? is not present. Previously, we returned Some(false) when ? was not present.

[SevInf]

Good job!