Add support in Storage RPC level for request with selected fields.

This topic was also discussed in #171.

Storage service allows getting partial blob or gcs object data using selected fields.

We could use that for exists checks and for listing calls + lazy load of the metadata when requested in the functional blobs.

This issue is an optimization only. If we think we want to expose the selected fields feature in the user level we should create a separate issue (and discuses how to make sure one does not override metadata
with partial metadata there).

I am working on this now. I wanted to provide fields selection for blob get and list. My idea was to allow this through a vararg of fields objects/enums. I would also like to encapsulate this in our XXXOption vargargs to avoid having other parameters floating around. This applies quite well to list:

storage.list("bucket", BlobListOption.fields(BlobField,contentType, BlobField.metadata));

For get we have instead BlobSourceOption that is used in several points across our API. In such points having BlobSourceOption.fields does not always make sense (think of update where selected fields are supported but we also have BlobTargetOption that might be used to specify them).
An alternative could be:

storage.get(BlobId, Iterable<BlobField>, BlobSourceOption...);

However, I don't like very much this signature.

Do you have any suggestion?

This issue was about adding the selective fields to the RPC (spi) layer rather than adding it to the API layer (so basically it is pure optimization for some operations such as exists).

Do you really think it would be useful to users? If so, what do you feel about creating a separate BlobReadOptions (similar to the BlobWriteOption you already created) to be used with get operation?