Recommendation for planned deprecation of `DaprClientHttp`

Given a DaprClient created like this...

```java
try (DaprClient client = (new DaprClientBuilder()).build()) {
...
}
```

...will result in a `DaprClientGrpc` by default.

When using `waitForSidecar` method, this exhibits the same behaviour as calling `v1.0/healthz` -- as this endpoint won't return success until both the components are initialised and the app channel is established.

---

We discovered this because in our Java app we are trying to read secrets from the secret component as part of the app initialisation, therefore before the app channel becomes available.

**The impact was the app dead locked with the sidecar.** Eventually `waitForSidecar` timeout elapsed, and the App crashed as it wasn't able to read the secrets that were depended later on.

---

I did some digging in the Java SDK code, and found that I could force the `DaprClientBuilder` to return a `DaprClientHttp` by doing the following.

```java
System.getProperties().setProperty(Properties.API_PROTOCOL.getName(), DaprApiProtocol.HTTP.name());
try (DaprClient client = (new DaprClientBuilder()).build()) {
...
}
```

In this case, when using `waitForSidecar` method, this exhibits the same behaviour as calling `v1.0/healthz/outbound` -- this endpoint returns successfully when the components are established, **but the app channel is not yet established.** which is exactly what we needed.

The impact was that we could successfully read secrets during the init phase of our Java App, without causing a Deadlock.

Unfortunately, now this means our code depends on a deprecated capability (`DaprClientHttp`), which is planned to be removed in the next version of the Java SDK, 1.10

---

My ask is that the following changes are made **before** `DaprClientHttp` is removed from the SDK.
- Migrate `waitForSidecar` in `DaprClientGrpc` to use `v1.0/healthz/outbound`
- This would then allow this issue to be closed without fix https://github.com/dapr/java-sdk/issues/897
- Introduce a new method called `healthCheck`, which has the same behaviour as calling `v1.0/healthz`

This will allow a migration path for us, and also bring [parity with the dotnet SDK](https://github.com/dapr/dotnet-sdk/blob/17f849b17505b9a61be1e7bd3e69586718b9fdd3/src/Dapr.Client/DaprClientGrpc.cs#L1742-L1785)