Bring your own connection library

[PadenZach]

Hey folks, I'd like to use asyncpg instead of psycopg2 for this library.

We strongly prefer asyncpg internally and would like to keep that consistency.

This would be a medium to large feature, but, it seems like it would be possible. Some big things we'd need to do is:

1. Create a new indirect SQL interface, and immediately support the existing psycopg connector
2. Convert all usage of psycopg2 to this new intermediate interface (seems doable, I mostly see dictrows and psycopg2.sql)
3. create a asyncpg plugin that uses the new interface. We could set this up such that both psycopg2 and asyncpg are optional dependencies, but that psycopg2 is the 'default'.

Just some rough thoughts, seems like a doable direction but given even if I found the time to do this it would be a large change and figured I'd ask if:

1. Would this feature be welcome? (likely coming in multiple PRs)
2. Any technical concerns on swapping out to another connection library?

[TkTech]

Sure, I can definitely see the value in it. I believe asyncpg supports everything needed like LISTEN/NOTIFY.

My main concern is how typing would work and how the _ex functions that take explicit cursors would work with different backends.