Simplify opentelemetry-proto: SDK decoupling, gRPC separation

[lalitb]

Related issue #2508

This issue proposes a refactor of the opentelemetry-proto crate to improve clarity, reduce unnecessary dependencies, and simplify usage for consumers of just the OTLP types.

🔄 Proposed Changes

1. Decouple opentelemetry-proto from SDK

• Remove opentelemetry-sdk as a dependency of opentelemetry-proto.
• Move transform logic (e.g., impl From<Resource> for proto::*) to opentelemetry-otlp, so opentelemetry-proto contains only wire format definitions.

2. Logical Re-exports for Protobuf Types

• Organize generated Protobuf messages (e.g., LogsData, LogRecord, etc.) under logical module paths like:

  proto::opentelemetry::proto::logs::v1::*

• This avoids consumers needing to depend directly on the file layout under src/proto/tonic.

3. Isolate gRPC Service Definitions

• Keep gRPC service definitions (e.g., LogsServiceClient, LogsServiceServer) in the same physical location (src/proto/tonic), but expose them only behind the gen-tonic feature via:

  proto::tonic::opentelemetry::proto::collector::logs::v1::*

4. Rename tonic Folder for Clarity (Optional)

• To reduce confusion, consider renaming src/proto/tonic to src/proto/generated since it contains both tonic and prost-generated code.
• Maintain tonic-specific exports in a mod tonic gated by the gen-tonic feature.

5. Remove gen-tonic-messages Feature

• This flag is no longer needed now that grpcio support has been dropped. All prost-based message generation should be unconditional.

---

✅ Benefits

• Consumers can use Protobuf messages (for file/HTTP ingestion) without pulling in tonic or SDK dependencies.
• Reduces compile times and simplifies the dependency tree.
• Improves modularity and aligns with crate responsibilities:
  • opentelemetry-proto: types only
  • opentelemetry-otlp: SDK + transform logic
  • gen-tonic: gRPC transport