Write docs on porting code to Trio

[njsmith]

There should be a section in the docs explicitly addressing the question: I need a library for Trio; it doesn't exist yet; what are my options?

Maybe the best arrangement is as a set of brief case studies, looking at how different libraries have handled this, and the tradeoffs involved in each choice. (What does your library do, do you care about sync, do you care about asyncio, do you care about taking advantage of native trio stuff, etc.)

Strategies to discuss (possibly incomplete):

• native Trio code (example: trio-websocket)
  • possibly with sans-I/O
  • special case for HTTP API wrappers (examples: gidgethub, this article from @pgjones's colleague)
• trio-asyncio:
  • to use existing asyncio libraries
  • to incrementally port an application from asyncio to trio
• unasync for "essentially sync" libraries:
  • with multiple I/O backends (urllib3)
  • with no backend b/c you're a middle-layer that doesn't do I/O anyway (flask)
• anyio

[dd-dent]

Not sure it's entirely related, but I'm itching to port stuff like this to trio...
Maybe a section with code examples from existing async/sync libraries as done via trio?
Or maybe a cookbook of sorts?

[oremanj]

https://github.com/python-trio/trio/issues/991#issuecomment-480405330 has an example of wrapping an "unfriendly" threaded API that might be useful as context for the sorts of porting problems people are facing.