Add uwsgi guidance to our documentation, similar to https://pymongo.readthedocs.io/en/stable/examples/mod_wsgi.html

Apps can, and in fact should, use both --lazy-apps and --enable-threads. --enable-threads is required for PyMongo to work so they must use it. --lazy-apps is not required but does help avoid the app having to deal with the fact that MongoClient is not fork-safe. References:

• https://pymongo.readthedocs.io/en/stable/faq.html?highlight=fork#is-pymongo-fork-safe
• https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html?#a-note-on-python-threads
• https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#preforking-vs-lazy-apps-vs-lazy

Are there any issues with using --py-call-osafterfork with --enable-threads?

The documentation for --py-call-osafterfork is very sparse (all it says is "enable child processes running cpython to trap OS signals") but from this open uwsgu issue I gather that this flag means that uwsgi will call PyOS_AfterFork_Child() in the forked child process. PyOS_AfterFork_Child() will call the "after_in_child" functions registered via os.register_at_fork. This flag enables uwsgi apps to trigger some cleanup or initialization code in the child process. For example an app could use this flag and os.register_at_fork+after_in_child to reinitialize any global MongoClients.