fix trait bounds on make `AsService` & `IntoService`

[Boog900]

The trait bounds on AsService & IntoService both require that M: Service, however this defeats the purpose of the types as if we already require that M: Service then all the ServiceExt methods would already be reachable on M.

This PR changes the bounds to M: MakeService.

[Boog900]

Just to add a bit more detail on why this is needed, see this issue: #253 and this PR: #492, this code is supposed to make this possible:

use tower::{make::MakeService, ServiceExt};

async fn example<T: MakeService<(), ()>>(mut t: T) {
    let _ = t.as_service().ready().await;
}

But currently this will give a compile error as T does not impl Service.

Just looking at the Service impl on AsService will show the mistake:

https://github.com/tower-rs/tower/blob/ec81e5797bb80ea7b65d243312db6ec2fdb6ce0e/tower/src/make/make_service.rs#L233-L237

M is required to impl Service, but it doesn't, that's why we need AsService as M doesn't impl Service it impls MakeService. We could add the Service bounds to T in my example but then that defeats the purpose of as_service/into_service.

If you instead pull in this patch you will see the example builds.

[ripytide]

Actually, after a bit more thought, while I still stand by that this PR fixes a accidental mistake in the blanket trait for implementing Service for all MakeServices. I don't actually see the point in the MakeService trait to begin with, in the docs it says its a trait alias, and some of the associated types/methods are named slightly differently, some are named the same as Service (like Future). Overall, I don't see it reducing the complexity of trait bounds for functions that take services returning other services and would probably choose to go without it in my own code.

And if you did want a trait alias making Service a super-trait of MakeService would make things a lot simpler.

Oh, I see MakeService is for where you don't want to explicitly implement Service to prevent it getting confused with regular Services. Hence the into_ and as_ methods that require explicit conversion. I'm still not sure it's worth the extra confusion of another trait though.

[Boog900]

@ripytide I guess this trait was more necessary when expressing trait bounds was more verbose. I can see the argument for removing this, with this PR fixing an issue though I am not sure this is the best place for that discussion, maybe a separate issue?