Serializable service factory

[mziccard]

This PR follows the discussion in #55.
It adds a ServiceFactory interface for service factories that extends Serializable.
A factory() getter is also added to the Service interface and implemented in the BaseService class.

Adding a Serializable ServiceFactory, as well as adding the factory() getter to the Service interface is not mandatory for having #55. It would have been enough to make StorageFactory serializable and add factory() getter to StorageService only. I did this bigger PR:

1. To maintain consistency across service interfaces
2. Because I think we might need a factory() getter also in other services, for the same reasons discussed in Should Blobs and Buckets be stateless or keep a reference to a StorageService ? #55

If anybody thinks these are too many changes, we can avoid merging this and I will make a Serializable factory only for StorageService.
Feedback is more than appreciated:)

/cc @aozarov @jgeewax @ajkannan

[aozarov]

@eamonnmcmanus given a serialize factory and serializable options we can always re-construct an instance of a service.

I think that can help us in many cases especially we want to provide a "continuous/lazy" functionality which in many cases is represented as a collection of serializable data (that is lazily created by the service).

This may open up a bigger discussion if we want our data holders to be serializable (issue #109) but
I would rather get more opinions about that if possible. I understand that Serialization could be nasty
but I still feel that it is kind of expected from plain data structure (considering the JDK itself and many
other libraries). In addition I didn't see much harm or future complication by requiring the factory to
be serializable but maybe I overlooked possible issues?

[aozarov]

@mziccard Sure, I am fine with putting this on hold and using an interface for ListResult as you proposed in #55. I suspect that if we do go head with this PR then it only means dropping one implementation of ListResutl, right?

SeriviceOptions is already serializable. Personally, I don't see a problem with a serialize factory.
Having both factory + options serializable means that we have an easy way to re-create a service at any point. I can think various use-cases for this being useful but supporting AE and being able to replace appengine_gcs_client is the one that I am currently have in mind. This one needs to be able to support functionality that starts in one process and resumable by other[s]. However, @eamonnmcmanus if you are not comfortable with that or even with the fact that data objects are serializable we can hold on with that for now (as @mziccard suggested).

[mziccard]

@aozarov We might still need the two implementations of ListResult, where in one we implement the lazy serialization of functional Blob list while in the other we just rely on default serialization. At least I cannot think of a way of doing this with a single class, correct me if I'm wrong.

[aozarov]

@mziccard I think the same implementation of ListResult could be used by providing different implementation for the Iterable<T> results param. One just returns BlobInfo and the other lazily converts BlobInfo into Blob per Iterator#next calls.

[mziccard]

@aozarov You are right 👍

[aozarov]

@mziccard I think we can close this one, right?