Using a Request trait with a type alias Response instead of two generic types

[stackinspector]

Note: This may be a sufficiently breaking change that it may be better to create another branch of this library and maintain it independently myself, rather than merging the changes into the current state of the library. The main purpose of this PR is discussion.
By using a Request trait with a type alias Response instead of two generic types, this library will be easier to use. In the future it could also be considered to allow transfering any type that implements Request in the channel by dynamic dispatching or something else. This would be more convenient when you need to pass values of multiple types, avoiding writing an enum and a lot of match boilerplate code.
Now I just finished the basic replacement and the current version does not compile through, with a kind of error that I can not understand and solve:

error[E0207]: the type parameter `R` is not constrained by the impl trait, self type, or predicates
   --> src\bounded.rs:127:6
    |
127 | impl<R: Request> ResponseReceiver<R::Response> {
    |      ^ unconstrained type parameter

error[E0207]: the type parameter `R` is not constrained by the impl trait, self type, or predicates
   --> src\bounded.rs:157:6
    |
157 | impl<R: Request> Responder<R::Response> {
    |      ^ unconstrained type parameter

error[E0207]: the type parameter `R` is not constrained by the impl trait, self type, or predicates
   --> src\unbounded.rs:109:6
    |
109 | impl<R: Request> UnboundedResponder<R::Response> {
    |      ^ unconstrained type parameter

For more information about this error, try `rustc --explain E0207`.
error: could not compile `bmrng` due to 3 previous errors

I found a similar case on Stack Overflow, but it doesn't seem to help me understand how to solve the current error.

[stackinspector]

The previous error has been solved and I finished adjusting tests.

[stackinspector]

Since I've been doing too much refactoring since then, I've created a new crate. if you think this PR doesn't fit your idea, it's time to close it.
BTW does my new crate need to have your name in the author list? I forgot to consider this before replying to you now. After all, despite being a straightforward encapsulation and it already looking very different, the main logic hasn't changed.