build: drop the gRPC transport that google-cloud-storage never uses here

[marevol]

Companion to codelibs/fess-crawler#200. Fess declares google-cloud-storage directly, so
the exclusions there do not reach it; the block here is the same one.

Why

GcsStorageClient builds its client with StorageOptions.newBuilder() — the
JSON-over-HTTP transport. The gRPC one is reachable only through StorageOptions.grpc(),
which nothing calls, but google-cloud-storage declares the dependencies of both.

Distribution zip: 218.9 MiB → 194.2 MiB (−24.7 MiB). 29 jars out, nothing in;
grpc-xds (10.5 MiB) and grpc-netty-shaded (10.3 MiB) are most of it.

After the change the war holds exactly two io.grpc jars, both deliberate:

grpc-api-1.82.2.jar
grpc-context-1.70.0.jar

and no opentelemetry-sdk-* or google-cloud-monitoring.

Three things deliberately kept

Kept	Why
io.grpc:grpc-api	HttpStorageRpc#startSpan opens an OpenCensus span on every request; OpenCensus keeps its span in io.grpc.Context, which has lived in grpc-api since gRPC 1.60.
proto-google-cloud-storage-v2	JsonConversions#bucketInfoDecode uses com.google.storage.v2.BucketName.
opentelemetry-api, -context, -common	gax-httpjson uses them.

Both of the first two were found by running fess-crawler's live GCS tests, not by reading
the dependency tree — excluding them compiles clean and then throws NoClassDefFoundError
on the first call. Details and stack traces are in codelibs/fess-crawler#200.

The OpenTelemetry SDK and the generated gRPC client are safe because, reading the constant
pools of google-cloud-storage-2.71.0.jar, the only class referencing io/opentelemetry/sdk
is OpenTelemetryBootstrappingUtils, whose only caller in the jar is GrpcStorageOptions.

Verification, and its limit

• Clean mvn package → BUILD SUCCESS; jar inventory and zip size as above.
• The library behaviour is covered by build: drop the gRPC transport that google-cloud-storage never uses here fess-crawler#200: 2057 tests including
  GcsClientTest against fsouza/fake-gcs-server, on the same google-cloud-storage
  version with the same exclusions.
• GcsStorageClientTest here is a stub-based unit test and does not touch the network.

I could not exercise GcsStorageClient against a live server, and the reason is a
separate pre-existing defect on master, not this change. Constructing the client throws
before it makes any request:

java.lang.NoSuchMethodError:
  'com.google.api.client.http.javanet.NetHttpTransport$Builder
   com.google.api.client.http.javanet.NetHttpTransport$Builder.setSecurityProvider(java.security.Provider)'
  at com.google.api.gax.httpjson.HttpJsonConscryptUtils.configureConscryptSecurityProvider
  at com.google.cloud.http.HttpTransportOptions$DefaultHttpTransportFactory.create
  ...
  at org.codelibs.fess.storage.GcsStorageClient.<init>(GcsStorageClient.java:106)

google-cloud-storage 2.71.0 needs google-http-client 2.x; fess-parent pins
google.http.client.version at 1.47.0 and this pom declares google-http-client,
-jackson2 and -xml at that version directly, so the direct declaration wins over the
2.2.0 the storage client asks for. grep google-http-client over the shipped war confirms
it: google-http-client-1.47.0.jar next to google-cloud-storage-2.71.0.jar.

I reproduced the same failure with an unmodified pom.xml, so it predates this PR and this
PR neither causes nor fixes it. It needs its own change — the bump is google-http-client
1.x → 2.x, which also affects OpenIdConnectAuthenticator and fess-ds-gsuite, so it wants
its own verification rather than being folded in here.