Inform application of MTU when reading

[chrysn]

This fixes the first half of #46 (informing the application, not checking), with some caveats:

• This is an API breaking change as users might destructure the ReadRequest struct. Future breakage of that kind is avoided by making the struct non_exhaustive.
• I don't know if 23 is really the default value -- and if the kernel guarantees that it's here, it might be better just to unwrap.
• Informing the application of the negotiated MTU is correct but requires some knowledge of mapping between MTUs and value lengths (which have a difference of 3). It might be better API to just expose the relevant length; ideally it should use the established name for that maximum. (Then the default would be 20).

The second half is harder to fix, as the response is sent through a channel without a back channel. It might be an option just to panic -- after all, it's like running copy_from_slice with an overly large slice.

[chrysn]

Ping -- how can we make progress here?

Do you have preferences as to whether the reported MTU or the usable slice length should be reported, and maybe experience as to whether that offset is always 3? (AIU the BLE specs it is, but I don't have a good overview of it.)

[dfrankland]

Sorry about that. I haven't been paying much attention since I stopped working on my BLE project. I was able to see that everything could build (I wasn't able to test), so I merged and published this.