Perf/journal caching

Extends the journal formatter's render method to be able to receive arbitrary options. The first application for this versatility is being able to pass a simple cache to the named association formatter.

The association formatter is used to render changes in associated objects. E.g. for an issue a change in priority is handled by this formatter. In order to be able to render the name (or similar identifier) of the associated object, it has to load it. This is done by using [Model-Constant].find_by_id.

As the formatters are independent instances for each change, each change in an associated object will lead to calling a find_by_id (Two calls to be percise - former value and new value). It is not necessary for each formatter to access the db. Rails SQL caching prevents the worst here. But when using an external caching like memcached, every find_by_id leads to an IPC-call. The performance overhead suffered can be circumvented when reusing loaded objects.

Therefore a simple cache is added that stores all loaded objects in the process itself. The result is a two-level caching. Objects are looked up in the in-process-cache. When no hit is made, the block provided is executed. For the named association formatter the fallback is still calling the find_by_id method. And this method is cached by the Rails SQL cache.

This pull request does not yet use the cache. This will be done by a separate pull request in order to keep it clean.

It might be desirable to optimize the caching strategy for some object types later on. One idea would be to always load all of the priorities. As there should always be just a few priority instances, instantiating them all should be cheaper than additional db-requests.