Cache effective attributes

When BGP performs adj-rib-in processing to derive effective-rib-in for a particular peer, we cache attribute from a particular message, so the same object is reused in the data store.

Since these cache objects are not carried across messages from a particular peer, when a peer advertises many routes (such that they don't fit into 4K) with same input attributes, we will end up using more data store memory than necessary.

https://git.opendaylight.org/gerrit/22133 adds such a cache, but it looks as though it needs to be reviewed and possibly debugged.