Worker enumeration

[justcoon]

fix: #295, #296

[vigoo]

do we need custom filter structure for Running worker enumeration, and all worker enumerations APIs? (for running workers Status filter is questionable)

I think there should be a single filter type, because the separation to two different queries only exists on the worker-executor level. So while it does not make too much sense to have a status filter for the method that only supports status==running, this is not an user facing API and the user facing one, exposed by worker-service, will have a single endpoint with a single filter type anyway. So I think we can live with this unnecessary impreciseness in our private API, instead of having to write all kind of conversion code between two almost similar types.

difference between grpc WorkerMetadata and golem-common WorkerMetadata (they do not contains retry_count)

Currently WorkerMetadata in golem-common is serialized into Redis except it's last_known_status field, while the gRPC one contains information which is almost the same, but in a more flat structure and information that a user should see. Retry count is probably something we could add to that, but for example last oplog index, and the jump table are not. So there is reason behind them not being completely the same.
Also, once the worker is done, golem-common's WorkerMetadata itself no longer need to be serializable and probably it can be moved to be a worker-executor specific internal type for in-memory information about workers. Will see when I get there

[vigoo]

Very nice! Added a few small comments, other than that it's very close to be merged