feat: Introduce YawnProjection.mapping

[luanpotter]

Sometimes we might want to have slightly more type-safe projection classes that are based on some minor transformation from the actual column types. Examples might include:

• combining one or two columns into a standardized data class used elsewhere in the codebase
• applying minimal in-memory processing to the values of certain columns
• compatibilizing a projection data-class that might be used on more than one query from different sources

While this could be accomplished by a two-step approach (i.e. have the projection match the exact database column types and then have a second data class and the appropriate wrappers), for some use cases that is cumbersome and unnecessarily boilerplate-y.

This adds a YawnProjection.mapping function that performs an in-memory post-processing to a projection value. This does not change the SQL query, but just uses Yawn strong type system to apply the transformation in-memory before building the resulting object.

[luanpotter]

[actually there is a bug in my implementation - let me revisit how we bind projections first]

[QuinnB73]

Coool!

[luanpotter]

went into a quick rabbit hole and started to re-do our entire projection infrastructure. will hold this until that is ready!