Correctly handle cancelled error with async operations

[darkdragon-001]

Without this, client code can't easily handle this exception as it is backend specific. Creating a common exception for both backends to hide this implementation detail.

In order to avoid breaking existing code expecting the backend specific error (for example via except trio.Cancelled or isinstance(e, trio.Cancelled) or the equivalent for asyncio.exceptions.CancelledError), we use multiple inheritance and then cast the existing error object to the inherited one (see here for more detail how this works).

Replaces #1251

[rthalley]

Trio application code does NOT catch the canceled exception, so there is no point in making a harmonized exception so applications can catch it. Also, dnspython's async abstraction is mostly so we can provide routines which do async I/O while using whatever the caller's preferred loop is. We're not trying to be a general purpose async I/O library abstraction like anyio. Please, no more changes in this area!

[darkdragon-001]

The current state is problematic with asyncio as the CancelledException caused by KeyboardInterrupt (Ctrl+C) requires special handling.