add support for channel manager delegates

[barbibulle]

Add support for application-supplied L2CAP channel manager delegates.
A delegate can make custom decisions about aspects of the policy that the channel manager should follow. By default a simple base implementation is used.
The current class only supports one delegation point, to accept/reject connection parameter update requests. Other delegation points may be added in the future.

[corby]

Thanks for putting this together — the delegate shape works for my case and I like that it's a policy hook rather than another flag. Two gaps from trying it against my setup:

1. accept_connection_parameters has no way to identify the connection. My Device is a single central with several peripherals connected concurrently (i'm using an NRF52480 dongle with a max of 4 connections), and the ChannelManager (and so the delegate) is per-Device. With only the four scalars I can't tell which peer sent the CPUR, so the policy is necessarily device-global — one peer mid-bulk-transfer forces me to refuse another peer's perfectly reasonable battery-saving request. Would you consider passing connection (or just the handle) as the first argument? That's the one thing that would let me drop my current handler override entirely.

2. Accept/reject only, no counter-offer. On accept, the peer's exact requested parameters are applied. Being able to return substitute parameters instead of True would cover the "I'll meet you partway" case, though this is less pressing than (1) and I'm happy to leave it for a future delegation point.
   The BLE spec allows for the central to adjust the requested connection parameters as long as they are within the min/max interval established. It also allows the central to override the timeout if the central detects a noisy envrironment (which we do).

Minor: the peripheral-side response changes from a CPUR Response with REJECTED to a Command Reject. Spec-correct as far as I can tell, but it's a wire-visible change that isn't called out in the description.

[barbibulle]

@corby You're right, the Connection context should have been there all along.
I have made a simple improvement to the delegate, so that now it can either reject the request by returning None, or accept the request, with optional changes, by returning a ConnectionParamaters object. By default, everything is accepted as-is.
Give it a try when you get a chance and let me know if that'd work for your purposes.