google-cloud-nio: transitive google-cloud-storage dependency causes scope conflicts when used at test scope

## Problem

`google-cloud-nio` is commonly used at `test` scope to provide a `java.nio.file.FileSystemProvider` for `gs://` URIs in tests. However, it depends on `google-cloud-storage` at compile scope, which pulls in ~15 transitive dependencies.

When a project already has `google-cloud-storage` at compile scope (e.g. via `spring-cloud-gcp-starter-storage`), adding `google-cloud-nio` at test scope can cause Maven's "nearest definition wins" rule to silently re-resolve `google-cloud-storage` and its transitives at test scope. Build tools that strip test-scoped jars from the runtime image (e.g. Jib) then produce containers with missing classes, causing `ClassNotFoundException` at startup.

The current workaround is to manually exclude `google-cloud-storage` from `google-cloud-nio`:

```xml

com.google.cloud
google-cloud-nio
test


com.google.cloud
google-cloud-storage

```

This is fragile and non-obvious. Every consumer hitting this has to independently discover the problem and apply the same fix.

## Suggestion

One of:

1. **Separate artifact:** publish a `google-cloud-nio-testing` artifact that contains only the `FileSystemProvider` registration and declares `google-cloud-storage` as `provided` or `optional`. This matches the pattern used by other GCP libraries (e.g. `google-cloud-bigtable-emulator-core`).

2. **Mark `google-cloud-storage` as `optional`:** in the existing `google-cloud-nio` POM, declare `google-cloud-storage` as `true`. Consumers already have it on the classpath at compile scope via their GCS integration. This avoids the transitive scope conflict without a new artifact.