Add support for pooling in codecs, partition_table, view etc.

[frairon]

Work in Progress

This is a draft for evaluating the efficiency and consequences of adding (memory) pooling to the goka API.

How it works

When processing messages with goka Processors, messages are decoded using a Codec in every callback call, as well as for every Join or Lookup. The same happens on every View.Get. When using more complex codecs like protobuf, those allocations add up and create pressure in the garbage collector. We would like to try reusing the messages. Protobuf supports Reseting the message upon unmarshalling, so they're a god fit for pooling.
Therefore we need to be able to tell the Codec when the message processing is done and the reference can be reused.

This PR adds a new decode-function called DecodeP which returns an io.Closer interface that must be called when the message can be reused.
Additionally, it also adds a GetP method to the storage.Storage interface to support pooling on disk-level, especially for Views.

[paulhenke]

Therefore we need to be able to tell the Codec when the message processing is done and the reference can be reused.

So codecs become stateful? Or were there already before?

[paulhenke]

What is this for, if all the code calling DecodeP is doing a nil check on the io.Closer return.

[frairon]

Thanks @paulhenke for all your comments. As said in some comments, the idea of this PR is to draft how pooling could be supported, although goka does not actually use it, only the clients. The codecs would become stateful in some sense, that's true, but they haven't been before and don't have to be. But breaking the API for this is probably a bad idea, so we'll design it in a way that both ways are supported.
But again, we're just in testing/drafting phase now and want to see if implementing all that actually brings some performance gains. If not, the whole thing is dropped right away. So the styling improvements will follow later.