V3 idea: Let {BatchRead,BatchUpdate,FindMissing}BlobsResponse use indices instead of digests (or none at all?)

The {BatchRead,BatchUpdate,FindMissing}BlobsRequest messages contain sequences of digests that need to be processed. The responses also contain the digests. The downside of this construct is that it requires some defensive code on the client side to account for the following scenarios. Think of the following cases:

1. What if these responses contain digests that weren't part of the request?
2. What if the same digest is reported in the response twice?
3. In the case of Batch{Read,Update}BlobsResponse: what if the response lacks entries that were part of the request?
4. What if the response contains elements in a different order?

Would it make sense to switch to different encodings that prevent (some of) these cases from existing? For example:

- FindMissingBlobsResponse could use a `repeated int32` to report blobs that are absent. That makes it easier to deal with case 1 by doing simple integer bounds checking. By requiring that these numbers are sorted, you can easily rule out case 2.
- Batch{Read,Update}BlobsResponse could simply omit the digest and require that the order corresponds with what was part of the request. That makes it easier to deal with case 1-4 by comparing just the length of the list in the response.

Start by reading the BatchReadBlobsRequest/Response, BatchUpdateBlobsRequest/Response, and FindMissingBlobsRequest/Response message definitions. Compare the proposed digest and index encodings against the four listed response-validation cases; done means the API choice and its ordering, omission, and duplicate rules are resolved.

Written by the indexing model from the issue text.