Add gRPC transport option for EncoderfileProvider (alternative to HTTP)

[dni138]

Tracking @javiermtorres's review summary comment on PR #160: #160 (review)

Related (pairs naturally with this): #164 (async support for HTTP-based providers).

Motivation

The encoderfile binary supports both HTTP and gRPC. We currently spawn with --disable-grpc and only use the HTTP /predict endpoint. gRPC would offer:

• Lower per-request overhead (binary framing vs JSON, HTTP/2 multiplexing).
• A proto-defined contract instead of best-effort JSON parsing.

Scope

• Add transport="http" | "grpc" constructor kwarg to EncoderfileProvider (default "http" to keep current behavior).
• New dependency: grpcio (~10 MB wheel) + grpcio-tools for codegen. Probably a sub-extra (encoderfile-grpc) so the default encoderfile extra stays minimal.
• Vendor encoderfile's .proto definition + generated stubs into the repo, with a CI step (or pre-commit hook) to regenerate when the upstream proto changes.
• Drop the --disable-grpc flag on the subprocess command when transport="grpc".

Cost / risk

• Doubles transport / error-handling surface inside the provider.
• Generated proto stubs need ongoing maintenance against upstream encoderfile.
• Throughput optimization without evidence of current pressure — purely speculative win at this point.

Suggested timing

Pairs naturally with #164. gRPC's Python client is async-native, so doing both together avoids touching the same provider files twice for the sync→async conversion.