GRPC interceptors: why is StreamInterceptor needed for unary RPCs?

We use the GRPC interceptor functionality to add authentication information to the metadata of the request.

When I add an `UnaryInterceptor` to the client it works fine for unary RPCs, however only when I call them with the method which returns a `Promise`.

If I call the same unary RPC with the methods which takes the callback as parameter, then the interceptor doesn't get executed but it would execute the `StreamInterceptor`.

I noticed that the generated code for the client has a seperate method in case there is a callback:
```
if (callback !== undefined) {
return this.client_.rpcCall(
```
otherwise it goes via
```
return this.client_.unaryCall(
```

I see in
https://github.com/grpc/grpc-web/blob/master/javascript/net/grpc/web/grpcwebclientbase.js

that `unaryCall` (`thenableCall`) uses the `unaryInterceptors_` but `rpcCall` uses the `streamInterceptors_`.

Why is this? I think it would be better to go through the same code path for doing a unary RPC no matter how the caller decided to invoke the RPC.

Otherwise I need to provide two interceptors for unary RPCs if the codebase uses both type of calls (callback and Promise based)