Allow releasing of stale connections back to pool.
I'm not sure how a connection would still be busy, since peewee will block until the query is finished. Furthermore, connections aren't returned to the pool until you call `close()` on them.

If you don't wish for connections to be marked stale, you can also modify the `stale_timeout` parameter (which, by default, is not set). @coleifer We've restructured the original application that brought us to this use case, but I submitted the PR in case there's a use for releasing connections to the pool rather than closing them.

You're correct that peewee blocks for queries, but I was thinking about what would happen if a different thread went through the connections and found one that passed `stale_timeout` while its original thread was still waiting for a response. The connection wouldn't be available to another thread, as it would be "checked out" by the connection that was using it. There's a lock around connect/close, so no race condition either.

Connections are released to the pool to be re-used when you call close() in the application. The pool itself will then close the connection if it is unusable or stale (if you've set up a stale timeout). @coleifer I seem to be overlooking the locks around connect/close in `PooledDatabase`, could you link me to it? They're in peewee's `Database` object. @coleifer That makes an awful lot more sense, thanks for clarifying. If you see no use for the PR (which no longer fits our own use case), feel free to close it.

With peewee blocking and waiting for responses, there might be a use case for someone that wants to use `stale_timeout` as a soft "release to pool" timeout that would assume the author didn't explicitly call close. Glad to help
Fine-grained control over the connection pool in non-web contexts can become more frustrating with the lightweight implementation because it's not implemented in peewee's core (e.g. after finishing a query, the connection isn't auto-released back to the pool), and in some structures context managers or decorators aren't desirable (requiring global access to the database's instance).

Adding this (very simple) option allows us to release connections back to the pool when they are stale rather than closing them entirely. This lets the user decide on how to manage what peewee considers stale connections.

There is one downside: the connection pool doesn't/can't know whether the query has finished so it's possible it will release busy connections back to the pool.

I hope this PR can serve as a discussion board for a better solution, because calling `Model._meta.database.close()` after every query or needing global access to the database's instance is not ideal.